Рукопожатие TLS 1.3 и возобновление сессии 0-RTT

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

В TLS 1.3 клиент и сервер завершают рукопожатие за 1-RTT (один цикл обмена). Клиент отправляет ClientHello, содержащий поддерживаемые наборы шифров и общую часть ключа (с использованием Диффи—Хеллмана). Сервер отвечает сообщениями ServerHello, передаёт собственную общую часть ключа, сертификат и первые зашифрованные данные приложения — всё одним пакетом. Затем клиент проверяет сертификат и отправляет сообщение Finished, после чего стороны обмениваются данными приложения.

TLS 1.3 требует эфемерного обмена ключами и полностью исключает обмен ключами RSA. Весь обмен ключами должен выполняться с использованием ECDHE (эфемерный Диффи—Хеллман на эллиптических кривых) или DHE (эфемерный Диффи—Хеллман). Слово «эфемерный» означает, что для каждого сеанса создаётся новая пара ключей. Это основа совершенной прямой секретности: компрометация долгосрочного закрытого ключа сервера не позволяет расшифровать прошлые сеансы, поскольку в каждом сеансе использовался уникальный временный ключ.

Совершенная прямая секретность (PFS) гарантирует, что даже если злоумышленник сегодня запишет весь зашифрованный трафик, а в будущем получит закрытый ключ сервера, он всё равно не сможет расшифровать старые сеансы. В TLS 1.2 с обменом ключами RSA закрытый ключ сервера мог расшифровать предварительный секрет в любом прошлом сеансе — это приводило к катастрофическим последствиям. Эфемерные ключи DH в TLS 1.3 означают, что каждый сеанс формирует собственные ключи, а после использования эти эфемерные ключи удаляются.

TLS 1.2 поддерживал более 300 наборов шифров, многие из которых были слабыми или взломанными. TLS 1.3 сокращает это число всего до пяти наборов шифров, и все они используют AEAD (аутентифицированное шифрование с дополнительными данными): TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 и TLS_AES_128_CCM_8_SHA256. Это устраняет целые категории атак, такие как BEAST, POODLE и FREAK, использовавшие слабое согласование шифров.

Возобновление 0-RTT (нулевое время обмена) — необязательная возможность TLS 1.3, позволяющая клиенту отправлять данные приложения уже в самом первом сообщении, до завершения рукопожатия. Она работает за счёт использования предварительно согласованного ключа (PSK) из предыдущего сеанса. Хотя 0-RTT значительно сокращает задержку — что особенно важно для API с высоким трафиком, — он создаёт существенный компромисс: ранние данные не защищены от атак повторной передачи.

При атаке повторной передачи данных 0-RTT злоумышленник, перехвативший сообщение с ранними данными, может повторно отправить его серверу, потенциально вызвав одно и то же действие дважды (например, платёж или изменение состояния). Спецификация TLS 1.3 прямо предупреждает, что ранние данные 0-RTT должны содержать только идемпотентные операции — операции, дающие один и тот же результат независимо от числа выполнений, например запрос GET. Неидемпотентные операции (POST, DELETE) никогда не должны использовать 0-RTT.

После успешного полного рукопожатия TLS 1.3 сервер отправляет сообщение NewSessionTicket, содержащее PSK (предварительно согласованный ключ), который клиент сохраняет. При повторном подключении клиент включает этот PSK в свой ClientHello с помощью расширения pre_shared_key. Сервер распознаёт его и либо разрешает данные 0-RTT, либо переходит к возобновлению 1-RTT. Билеты PSK имеют ограниченный срок действия, и их следует часто заменять, чтобы сократить период возможного раскрытия.

Важное улучшение TLS 1.3 заключается в том, что большая часть рукопожатия шифруется, включая сертификат сервера. В TLS 1.2 сертификат сервера передавался в открытом виде, что позволяло наблюдателю в сети определить домен, к которому подключался клиент. TLS 1.3 шифрует сертификат и большинство последующих сообщений рукопожатия, уменьшая объём метаданных, доступных пассивным наблюдателям. Зашифрованный Client Hello (ECH) — это развивающееся расширение, скрывающее даже поле SNI (индикация имени сервера).

TLS 1.3 удалил множество устаревших возможностей, которые стали источниками уязвимостей: обмен ключами RSA (отсутствие прямой секретности), наборы шифров в режиме CBC (уязвимость к атакам с оракулом дополнения), RC4 (полностью взломанный потоковый шифр), криптографию экспортного уровня (причина атак FREAK и Logjam), MD5 и SHA-1 в цифровых подписях, сжатие (причина атаки CRIME) и повторное рукопожатие (причина нескольких атак). Благодаря этому TLS 1.3 имеет значительно меньшую поверхность атаки.

Для корректного развёртывания TLS 1.3 необходимо настроить веб-сервер на его предпочтительное использование и отключить TLS 1.0 и 1.1. Большинство современных веб-серверов (Nginx, Apache, IIS) поддерживают TLS 1.3 изначально. Также убедитесь, что включена проверка статуса сертификата OCSP Stapling, позволяющая получать сведения об отзыве сертификата без обращения клиента к CA, а заголовки HSTS предотвращают атаки на понижение версии до HTTP. Используйте такие инструменты, как SSL Labs, чтобы проверить, что Ваша конфигурация получает рейтинг A+.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

В этом уроке Вы узнали, что TLS 1.3 завершает рукопожатие за 1-RTT, используя только эфемерный обмен ключами DH для обеспечения совершенной прямой секретности; возобновление 0-RTT ускоряет повторное подключение с помощью PSK, но уязвимо к атакам повторной передачи и должно использоваться только для идемпотентных операций; а TLS 1.3 удаляет все устаревшие слабые возможности — обмен ключами RSA, шифры CBC, RC4, экспортную криптографию и сжатие, — значительно уменьшая поверхность атаки. Далее мы рассмотрим алгоритмы аутентифицированного шифрования, такие как AES-GCM.