TLS 1.3: 0-RTT, ранние данные и возобновление сессии

TLS 1.3 (RFC 8446, 2018) переработал рукопожатие TLS, чтобы уменьшить задержку и устранить устаревший балласт. Полное рукопожатие TLS 1.3 завершается за 1-RTT: клиент отправляет ClientHello с поддерживаемыми key_shares (эфемерными открытыми ключами ECDH) в первом сообщении; сервер отвечает сообщениями ServerHello, своим key_share, зашифрованными расширениями, сертификатом и сообщением о завершении — всё в одном ответе. Клиент отправляет своё сообщение о завершении и может сразу передавать данные приложения. По сравнению с рукопожатием TLS 1.2 за 2-RTT это вдвое сокращает время установления нового соединения.

TLS 1.3 использует HKDF (функцию выработки ключа на основе HMAC) со структурированной схемой выработки ключей. После обмена ключами ECDHE общий секрет проходит через иерархию: Extract(early_secret, DHE) -> handshake_secret; затем Extract(handshake_secret, 0) -> master_secret. На их основе HKDF-Expand-Label выводит отдельные ключи для трафика рукопожатия клиента и сервера, трафика приложения и возобновления сеанса. Чёткое разделение гарантирует, что компрометация одного слоя ключей не затронет остальные, что значительно лучше более произвольной выработки ключей на основе PRF в TLS 1.2.

Для возобновления сеанса TLS 1.3 используются предварительно распределённые ключи (PSK), полученные из предыдущих сеансов. После завершения рукопожатия сервер отправляет сообщение NewSessionTicket, содержащее идентификатор PSK и значение билета — зашифрованный блок данных с секретом возобновления. При повторном подключении клиент включает идентификатор PSK в ClientHello. Если сервер его распознаёт, обе стороны выводят новый ключ сеанса из PSK и свежего ECDHE, обеспечивая возобновление за 1-RTT с прямой секретностью. Для билета настраивается срок действия (обычно 24 часа), и его следует шифровать регулярно меняющимся ключом на стороне сервера.

TLS 1.3 разрешает ранние данные 0-RTT для возобновлённых сеансов. Клиент использует PSK из предыдущего сеанса, чтобы зашифровать данные приложения, отправляемые в первой серии сообщений — до любого подтверждения сервера. Это устраняет один обмен сообщениями при подключении к ранее посещённым серверам и обеспечивает почти нулевую задержку при повторных подключениях. Сервер объявляет поддержку 0-RTT в NewSessionTicket с помощью расширения early_data и параметра max_early_data_size. Сервер должен иметь механизм принятия или отклонения данных 0-RTT и сообщает о принятии в EncryptedExtensions.

Данные 0-RTT имеют фундаментальное ограничение безопасности: они уязвимы для атак повторного воспроизведения. Атакующий, находящийся на пути передачи и перехвативший первую серию сообщений, может воспроизвести её для сервера, заставив сервер обработать ранние данные повторно. Это неизбежно: сервер ещё не отправил ни одного сообщения, поэтому отсутствует добавленная сервером новизна. Меры защиты: (1) Билеты однократного использования — сервер делает билет недействительным после первого использования, применяя распределённый кэш, например memcached/Redis. (2) Билеты с ограниченным сроком действия — отклонять 0-RTT по истечении короткого окна, например 5 секунд. (3) Идемпотентность на уровне приложения — разрешать 0-RTT только для безопасных операций, эквивалентных GET.

Наиболее надёжный механизм защиты 0-RTT от повторного воспроизведения — это билеты сеанса однократного использования. Сервер поддерживает хранилище использованных билетов, которое в многосерверных развёртываниях является распределённым кэшем. Когда поступают данные 0-RTT, сервер проверяет, встречался ли билет ранее: если да, он отклоняет ранние данные и переходит к 1-RTT. Если нет, он помечает билет как использованный и обрабатывает ранние данные. Для корректной работы все серверы в кластере должны совместно использовать кэш использованных билетов. Redis с короткими TTL, соответствующими сроку действия билета, является распространённой реализацией. Без этого механизма 0-RTT небезопасен для неидемпотентных операций, таких как платежи.

Возобновление TLS 1.3 с помощью PSK без DHE не обеспечивает прямой секретности возобновлённого сеанса: если PSK впоследствии будет скомпрометирован, весь трафик возобновлённых сеансов можно будет расшифровать. Для сохранения прямой секретности TLS 1.3 поддерживает режим PSK-with-DHE: ClientHello включает идентификатор PSK и новый key_share. Сервер объединяет PSK и результат ECDHE для выработки ключей сеанса. Даже при компрометации PSK вклад ECDHE обеспечивает защиту прошлого трафика. RFC 8446 рекомендует PSK-with-DHE во всех случаях возобновления, где требуется прямая секретность.

В TLS 1.2 было более 300 комбинаций наборов шифров, многие из которых были небезопасны. TLS 1.3 сокращает их число до 5 наборов шифров, все они используют 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. Обмен ключами и аутентификация согласовываются отдельно с помощью расширений supported_groups и signature_algorithms. Такое разделение устраняет комбинаторную сложность TLS 1.2 и гарантирует, что каждое соединение TLS 1.3 использует аутентифицированное шифрование.

На практике 0-RTT наиболее полезен для соединений HTTP/2, когда клиент повторяет запрос GET (безопасный и идемпотентный) к ранее посещённому серверу. Браузеры реализуют 0-RTT осторожно: Chrome включает его для безопасных методов HTTP, а запросы POST никогда не отправляются как данные 0-RTT. HTTP/3 через QUIC изначально интегрирует TLS 1.3 — 0-RTT в QUIC повторно использует механизм TLS 1.3. В QUIC 0-RTT также восстанавливает параметры транспорта (управление потоком, ограничения потоков) из предыдущего сеанса, дополнительно уменьшая накладные расходы на установление соединения, а не только на уровне TLS.

TLS 1.3 включает механизмы защиты от атак с понижением версии. Поле случайных данных ServerHello содержит специальное значение, когда согласован TLS 1.3: последние 8 байтов устанавливаются в фиксированное значение (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 для возврата к TLS 1.2). Клиенты с поддержкой TLS 1.3 проверяют это значение, когда сервер согласовывает TLS 1.2, обнаруживая активные попытки понижения версии. Кроме того, хэш транскрипции сообщения о завершении охватывает всё рукопожатие, включая согласование версии, поэтому любое вмешательство можно обнаружить. SCSV (сигнальные значения набора шифров), например TLS_FALLBACK_SCSV, предоставляют отдельный сигнал понижения версии для более старых версий TLS.

Развёртывание TLS 1.3 требует внимания к нескольким эксплуатационным аспектам. Ключи шифрования билетов сеанса необходимо регулярно менять (обычно каждые 24 часа) и синхронизировать между кластерами серверов, чтобы возобновление было возможно на любом сервере. Старые ключи расшифрования билетов нужно сохранять в течение срока действия билета, чтобы избежать ложных сбоев рукопожатия. Прикрепление ответа OCSP важнее в TLS 1.3, поскольку для проверки статуса сертификата требуется на один обмен сообщениями меньше. Балансировщики нагрузки должны пропускать ClientHello TLS 1.3 без изменений: некоторые устаревшие промежуточные сетевые устройства повреждают неизвестные расширения, поэтому требуются режимы совместимости.

Почему ранние данные 0-RTT уязвимы для атак повторного воспроизведения в TLS 1.3?

TLS 1.3 обеспечивает полноценное рукопожатие за 1-RTT и возобновление за 0-RTT с помощью билетов сеанса PSK. Для выработки ключей используется HKDF со структурированной схемой, создающей отдельные ключи для каждого слоя трафика. Ранние данные 0-RTT устраняют один обмен сообщениями, но уязвимы для повторного воспроизведения; эту угрозу снижают билеты однократного использования и ограничение 0-RTT идемпотентными операциями. PSK-with-DHE сохраняет прямую секретность при возобновлении. TLS 1.3 ограничивает наборы шифров пятью вариантами AEAD, устраняя устаревшие небезопасные комбинации. Защита от понижения версии использует специальные значения в поле случайных данных сервера.