Расписание ключей, SNI, ALPN и расширения

Вы понимаете, как ECDHE производит общий секрет. Но этот секрет не используется напрямую как ключ шифрования — он поступает в дерево выведения ключей, которое производит отдельные ключи для трафика рукопожатия, трафика приложения, возобновления и экспорта. Это дерево — расписание ключей HKDF, и каждый ключ, используемый TLS 1.3, вытекает из него.

Расписание ключей HKDF (RFC 8446 §7.1)

TLS 1.3 выводит каждый ключ из двухфазного дерева HKDF:

Фаза 1 — Early Secret.

early_secret = HKDF-Extract(salt=0, IKM=PSK_or_zero)

Если нет PSK: IKM — все нули. Из раннего секрета Derive-Secret(early_secret, "derived", "") производит соль для фазы 2.

Фаза 2 — Handshake Secret.

handshake_secret = HKDF-Extract(salt=derived_from_early, IKM=ECDHE_shared_secret)

Из секрета рукопожатия:

• Ключ трафика клиента рукопожатия: HKDF-Expand-Label(hs_secret, "c hs traffic", transcript, hash_len)
• Ключ трафика сервера рукопожатия: HKDF-Expand-Label(hs_secret, "s hs traffic", transcript, hash_len)

Фаза 3 — Master Secret.

master_secret = HKDF-Extract(salt=derived_from_handshake, IKM=zero)

Из мастер-секрета:

• Ключ трафика приложения клиента: HKDF-Expand-Label(master, "c ap traffic", transcript, hash_len)
• Ключ трафика приложения сервера: HKDF-Expand-Label(master, "s ap traffic", transcript, hash_len)
• PSK возобновления: Derive-Secret(master, "res master", transcript)

Метки ("c hs traffic", "s ap traffic" и т.д.) — разделители доменов: компрометация одного пути вывода ключей не может помочь злоумышленнику на другом пути.

Разделение наборов шифров в TLS 1.3

TLS 1.2 упаковывал три выбора в одну строку набора шифров: обмен ключами, массовый шифр и MAC. TLS 1.3 разделил их:

• Согласование именованных групп — выбирает кривую ECDHE (x25519, secp256r1, …)
• Согласование алгоритмов подписи — выбирает способ верификации подписи сертификата (ecdsa_secp256r1_sha256, ed25519, …)
• Набор шифров — выбирает только шифр AEAD и хэш для расписания ключей: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_256_GCM_SHA384

В TLS 1.2 было сотни допустимых комбинаций. В TLS 1.3 — пять стандартных наборов.

SNI: указание имени сервера

Многие имена хостов разделяют один IP-адрес (виртуальный хостинг, CDN). Без дополнительной информации сервер не может выбрать правильный сертификат до чтения запроса — запрос зашифрован. SNI решает эту проблему, заставляя клиента отправлять имя хоста в открытом виде внутри ClientHello. Сервер использует его для выбора правильного сертификата перед ответом.

Цена конфиденциальности: любой в сети узнаёт, какой именно хост вы посетили. Это мотивация для Encrypted ClientHello (ECH), рассматриваемого в следующем уроке.

ALPN: согласование протокола прикладного уровня

После установки TLS клиент и сервер должны договориться о протоколе выше: HTTP/1.1, HTTP/2 или HTTP/3. ALPN помещает список в ClientHello (обычно ["h2", "http/1.1"]), и сервер выбирает один в ServerHello. Поскольку оба сообщения защищены хэшем транскрипта, промежуточный узел не может удалить h2, чтобы принудительно использовать HTTP/1.1 — вмешательство нарушает Finished.

HelloRetryRequest

Если key_share клиента содержит только кривую, которую сервер не поддерживает, сервер отправляет HelloRetryRequest (закодированный как специальный ServerHello со значением magic_retry_request_random), содержащий cookie и желаемую именованную группу. Клиент отправляет новый ClientHello с правильным key_share и cookie. Это добавляет один RTT, но встречается редко: современные клиенты предлагают x25519 и P-256 одновременно, чтобы предотвратить это. Cookie также позволяет серверам без сохранения состояния (балансировщикам нагрузки без привязки соединений) завершить HRR без сохранения состояния между двумя ClientHello.

OCSP-прикрепление и CRLite

Традиционный OCSP: клиент делает живой запрос к OCSP-ответчику CA для проверки отзыва — что раскрывает историю просмотров и добавляет задержку. OCSP-прикрепление переносит это на сервер: сервер периодически получает подписанный OCSP-ответ и прикрепляет его к TLS-рукопожатию через расширение status_request. Никакого дополнительного обращения клиента, никакой утечки конфиденциальности.

Реальность после 2024 года: Let’s Encrypt прекратил обслуживание OCSP 2025-05-07. Firefox 137 поставил CRLite по умолчанию — компактный, подписанный каскад фильтров Блума, охватывающий все отзывы WebPKI из журналов CT, обновляемый каждые 12 часов. Новая инфраструктура должна ориентироваться на 90-дневные (скоро 47-дневные) сроки жизни сертификатов вместо OCSP в реальном времени.

Прозрачность сертификатов (CT)

Каждый публично доверенный сертификат должен появляться как минимум в двух журналах CT — добавляемых только, публично проверяемых, подписанных деревьях Меркла. Клиент проверяет, что сертификат содержит Signed Certificate Timestamps (SCT). Chrome и Safari отклоняют соединения с отсутствующими или недействительными SCT. CT сделала экосистему CA проверяемой: недобросовестный CA не может выдать сертификат для example.com, не оставив публичной записи с защитой от фальсификации, а инструменты обнаружения (crt.sh) оповещают владельцев доменов в течение минут.