В марте 2026 года IETF опубликовал RFC 9849 в окончательной версии. Таким образом, стандарт зашифрованного рукопожатия TLS Encrypted Client Hello (ECH) для зашифрованного DNS (Encrypted DNS) принят официально.
TLS ECH и раньше применялся некоторыми серверами и браузерами, хотя российский РКН рекомендовал отключить его во избежание случайной фильтрации трафика. Раньше ECH считалась «нестандартной» технологией, а сейчас стала официальным стандартом, который браузеры включают по умолчанию (DNS-over-TLS, DoT, или DNS-over-HTTP, DoH).
Однако для шифрования трафика нужно, чтобы шифрование обе стороны — и браузеры, и серверы.
Этот процесс идёт очень медленно во всём мире, не говоря уже про российский сегмент с его спецификой.
Зашифрованное рукопожатие
TLS ECH — это зашифрованная часть рукопожатия TLS, с указанием доменного имени, к которому хочет подключиться клиент. Раньше она передавалась в открытом виде даже при TLS-шифровании канала, и это считалось серьёзной утечкой информации. Поэтому появился Encrypted SNI, который шифровал только поле имени сервера и имел известные уязвимости. ECH пришёл ему на смену, он шифрует чувствительную часть рукопожатия (Inner ClientHello) и закрывает пробелы ESNI.
Теперь поле Server Name Indication (SNI) в TLS ClientHello становится нечитаемым для всех наблюдателей, файрволов, сканеров и других инструментов мониторинга трафика. В этом есть и минусы.
Что ломается с ECH:
Фильтрация трафика на основе SNI
Правила обнаружения и индикаторы компрометации по именам хостов
Проксирование TLS через агента на конечной точке. Браузер с поддержкой ECH рассматривает перехват трафика как атаку, потому что именно для этого и был разработан протокол
Системы отчётов и планирования трафика, которые работают с именами хостов
Любая архитектура, основанная на чтении SNI без расшифровки трафика
В спецификации RFC 9849 указано, что для шифрования скрытой части ClientHello используется схема Hybrid Public Key Encryption (HPKE) на базе открытого ключа сервера, как описано в RFC 9180. Конфигурация ECH определяется следующей структурой ECHConfig, которую нужно сгенерировать на стороне веб-сервера, и выложить публичный компонент в DNS в виде HTTPS-записи.
opaque HpkePublicKey<1..2^16-1>; uint16 HpkeKemId; // Defined in RFC 9180 uint16 HpkeKdfId; // Defined in RFC 9180 uint16 HpkeAeadId; // Defined in RFC 9180 uint16 ECHConfigExtensionType; // Defined in Section 11.3 struct { HpkeKdfId kdf_id; HpkeAeadId aead_id; } HpkeSymmetricCipherSuite; struct { uint8 config_id; HpkeKemId kem_id; HpkePublicKey public_key; HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>; } HpkeKeyConfig; struct { ECHConfigExtensionType type; opaque data<0..2^16-1>; } ECHConfigExtension; struct { HpkeKeyConfig key_config; uint8 maximum_name_length; opaque public_name<1..255>; ECHConfigExtension extensions<0..2^16-1>; } ECHConfigContents; struct { uint16 version; uint16 length; select (ECHConfig.version) { case 0xfe0d: ECHConfigContents contents; } } ECHConfig;
Генерация пары ключей:
$ openssl ech -public_name example.com -out example.com.pem.ech
Файл .pem содержит приватный ключ (чтобы Nginx мог декодировать входящие сообщения ECH) и ECHConfig для публикации в DNS через запись HTTPS:
$ dig +short HTTPS foo.example.com 1 . ech=AD7+DQA6QwAgACA8mxkEsSTp2xXC/RUFCC6CZMMgdM4x1i TWKu3EONjbMAAEAAEAAQALZXhhbXBsZS5vcmcAAA==
Внедрение задерживается
Переход на шифрование SNI будет небыстрым, хотя Chrome, Edge, Firefox и Brave включают ECH по умолчанию при использовании зашифрованного DNS. Например, Firefox это делает по умолчанию с версии 119. Здесь исключением является Safari, что само по себе уже мешает внедрять ECH повсеместно на серверной стороне.
Серверы очень медленно подключают ECH. Исследование Corrata в мае 2025 года показало, что примерно 20% пользовательских устройств настроено на использование зашифрованного DNS, при этом реальное использование ECH составляет всего 0,06% от всех подключений.
Почему так происходит? Ответ можно получить из другого исследования, проведённого в феврале 2025 года. Это была пассивная прослушка сети университета примерно на 35 тыс. пользователей. Оно выявило, что 59% соединений QUIC содержали расширение ECH, но только 1,96% на самом деле были ECH. Остальная часть представляла собой GREASE-ECH — фиктивный ECH-блок от Chromium-браузеров. Все валидные соединения ECH шли к Cloudflare, то есть это был единственный реальный провайдер ECH.
Cloudflare фактически был единственным CDN, который использовал ECH в продакшне.
Принятие официального стандарта в 2026 году мало что изменило. Внедрение ECH идёт крайне медленно. Ни один другой крупный CDN не объявил о поддержке ECH с момента публикации стандарта RFC.
Реалистичный горизонт для внедрения ECH оценивают от двух до четырёх лет. Публикация RFC стала важным этапом, потому что CDN и поставщики безопасности не будут внедрять протокол, который находится в черновиках IETF. Разработчики библиотеки OpenSSL добавили поддержку ECH только после принятия официального стандарта, в марте 2026-го. Разработчики веб-сервера Nginx сделали это с версии 1.29.4, см. инструкцию по настройке сервера.
Следующим важным событием станет внедрение ECH другими крупными CDN, кроме Cloudflare.
Вот тогда можно будет констатировать, что процесс пошёл.
