TLS ECH официально принят как RFC 9849. Что теперь?

В марте 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.