TLS и защищенные каналы

Transport Layer Security (TLS) — это протокол, который обеспечивает безопасность большей части интернет-коммуникаций, сочетая аутентифицированный обмен ключами и аутентифицированное шифрование для создания конфиденциального, защищенного от подделок канала между двумя конечными точками.

Definition

Протокол защищенного канала, такой как TLS, устанавливает между двумя сторонами сеанс, который гарантирует конфиденциальность, целостность и аутентификацию всех обмениваемых данных, путем выполнения аутентифицированного обмена ключами с последующим аутентифицированным шифрованием трафика.

Scope

Эта тема охватывает протоколы защищенных каналов, с TLS в качестве центрального примера: рукопожатие, которое аутентифицирует сервер (и опционально клиента) и устанавливает сеансовые ключи, уровень записей, который обеспечивает аутентифицированное шифрование, прямую секретность и защиту от понижения версии, а также уроки, извлеченные из исторических атак. В ней рассматривается, как криптографические строительные блоки собираются в развернутый протокол. Она исключает инфраструктуру сертификатов (PKI) и отдельные примитивы, которые рассматриваются в смежных темах.

Core questions

• Как рукопожатие TLS аутентифицирует сервер и согласовывает сеансовые ключи?
• Как уровень записей защищает каждое сообщение с помощью аутентифицированного шифрования?
• Как достигается прямая секретность и почему это важно для записанного трафика?
• Как предотвращаются атаки понижения версии и пересогласования?
• Чему научили исторические атаки (BEAST, POODLE, Heartbleed) в отношении проектирования протоколов и реализаций?

Key concepts

• рукопожатие TLS
• уровень записей
• аутентифицированное шифрование (AEAD)
• эфемерный обмен ключами (ECDHE)
• прямая секретность
• аутентификация сервера и клиента
• атаки понижения версии и пересогласования
• возобновление сеанса
• согласование набора шифров

Key theories

Рукопожатие плюс протокол записей

TLS разделяет рукопожатие для аутентифицированного обмена ключами — которое проверяет личность с помощью сертификатов и выводит сеансовые ключи — от уровня записей, который шифрует и аутентифицирует данные приложения с помощью этих ключей, чисто объединяя аутентификацию, согласование ключей и массовую защиту.

Прямая секретность и защита от понижения версии

TLS 1.3 предписывает эфемерный (эллиптические кривые) Диффи-Хеллман для прямой секретности и связывает транскрипт рукопожатия с расписанием ключей, чтобы активный злоумышленник не мог незаметно принудительно понизить версию до более слабых параметров.

Mechanisms

В TLS 1.3 клиент отправляет свои доли обмена ключами и поддерживаемые параметры; сервер отвечает своей собственной эфемерной долей Диффи-Хеллмана, сертификатом и подписью транскрипта рукопожатия, и обе стороны выводят сеансовые ключи с помощью функции вывода ключей (HKDF). Затем уровень записей защищает все данные с помощью шифра AEAD (такого как AES-GCM или ChaCha20-Poly1305). Транскрипт аутентифицируется для предотвращения подделки или понижения версии, и рукопожатие завершается за один раунд, с опциональным возобновлением с нулевым раундом.

Clinical relevance

TLS обеспечивает безопасность подавляющего большинства интернет-трафика: HTTPS для веб-сайтов, безопасная электронная почта, API, VPN и мессенджеры — все они работают поверх него. Его корректность напрямую определяет, защищены ли пароли, платежи и персональные данные от сетевых злоумышленников. Переход от несовершенных SSL/ранних версий TLS к TLS 1.3 — и сопровождавший его анализ — является моделью эволюции протоколов под давлением реального мира.

Evidence & guidelines

TLS 1.3 стандартизирован в RFC 8446 и рекомендуется к использованию; SSL 3.0, TLS 1.0 и TLS 1.1 устарели (RFC 8996). NIST SP 800-52 предоставляет рекомендации по конфигурации. TLS 1.3 был разработан с обширным формальным анализом, устраняющим устаревшие уязвимости (статический обмен ключами RSA, режим CBC, пересогласование), которые позволяли проводить более ранние атаки, такие как BEAST, POODLE, и уязвимость реализации Heartbleed.

History

Netscape создала SSL в 1994-1995 годах; SSL 3.0 был переработан IETF как TLS 1.0 (1999) и доработан до TLS 1.2 (2008). Десятилетие атак — BEAST, CRIME, POODLE, ошибка реализации Heartbleed, Logjam и FREAK — выявило уязвимости в устаревших режимах и обработке понижения версии. TLS 1.3 (RFC 8446, 2018) представлял собой серьезную переработку с обязательной прямой секретностью, более быстрым рукопожатием и формальным анализом безопасности.

Key figures

• Eric Rescorla
• Hugo Krawczyk
• Kenny Paterson
• Taher ElGamal

Seminal works

• rfc8446
• stallings2017
• katz2020

Frequently asked questions

В чем разница между SSL и TLS?

TLS является преемником SSL. SSL (версии 2.0 и 3.0) устарел и небезопасен; «SSL» сохраняется как разговорный термин, но все текущие безопасные веб-соединения используют TLS, при этом TLS 1.3 является современной версией.

Защищает ли TLS от вредоносного веб-сайта?

TLS гарантирует только, что у вас есть конфиденциальный, аутентифицированный канал к серверу, указанному в сертификате — он подтверждает, что вы общаетесь с этим доменом, а не то, что домен заслуживает доверия. Фишинговый сайт может предоставить действительный сертификат для своего собственного (похожего) домена, поэтому TLS не ручается за честность сайта.