Кратко

  • ECH шифрует приватный ClientHelloInner с настоящим SNI и переносит его внутри публичного ClientHelloOuter.
  • Результат зависит от доставки актуальной конфигурации через DNS, ключа на фронтенде, подтверждения backend и контролируемого отказа без тихого понижения защиты.
  • DNS-запрос, IP-адрес и корреляция трафика остаются отдельными сигналами; параметр ech в зоне не доказывает принятую сессию.

Открытым был первый вопрос

Расширение server_name в RFC 6066 позволило выбирать один сервис среди нескольких на общей инфраструктуре. По RFC 8446 ClientHello остаётся первым сообщением TLS 1.3. Имя поэтому появлялось раньше, чем шифровалась большая часть рукопожатия.

RFC 9849, опубликованный как Standards Track в марте 2026 года, создаёт внутреннее и внешнее приветствие. Внутреннее содержит настоящий SNI и другие чувствительные параметры. Клиент шифрует его через HPKE с публичным ключом из ECHConfig. Внешнее несёт публичные значения и расширение с запечатанным блоком.

Фронтенд принимает ECH и обрабатывает или пересылает внутреннее приветствие. Если открыть его нельзя, сервер использует внешнее и может вернуть свежие конфигурации. Клиент проверяет принятие. Соединение, где ECH предлагался, но был отклонён, не используется для данных приложения: отказ ведёт к повтору, а не маскируется под защищённый успех.

Общий вход получает отдельную власть

В совместном режиме фронтенд сам завершает TLS. В разделённом он раскрывает только внутреннее приветствие и передаёт его отдельному backend, который завершает TLS. Фронтенд узнаёт имя для маршрутизации, но не обязан завершать защищённый поток приложения.

Владелец DNS публикует конфигурацию. Клиент решает её предложить. Фронтенд хранит приватный ключ и прежние значения, которые ещё встречаются в кэше. Backend связывает подтверждение с внутренней транскрипцией. Локальный успех одного участника не доказывает всю цепь.

Ротация создаёт компромисс. Быстрая смена сокращает последствия компрометации ключа, но увеличивает число клиентов со старой конфигурацией. Слишком много старых ключей увеличивает пробную расшифровку. RFC задаёт процедуру, а не общий интервал.

DNS доставляет инструкцию до TLS

RFC 9848 определяет параметр ech для записей SVCB и HTTPS из RFC 9460. До соединения клиент получает альтернативные endpoints и их параметры.

Если RRSet смешивает endpoints с ECH и без него, посредник может блокировать защищённые и оставить открытый. RFC 9848 не рекомендует такую схему. Блокирование самого SVCB-разрешения может не дать клиенту узнать, что защита была настроена.

Шифрованный DNS скрывает вопрос от локального наблюдателя, но не от рекурсивного резолвера. Адрес фронтенда остаётся видимым. ECH защищает конкретное поле рукопожатия, а не делает маршрут анонимным.

Множество должно выглядеть единым

Несколько имён должны разделять конфигурацию и похожее публичное поведение. Отдельный идентификатор для каждого имени может сократить множество до одного. Уникальные наборы шифров, порядок расширений, границы записей или retry-cookie также выделяют backend.

Внутренний блок может быть зашифрован верно, а внешний — служить меткой. Проверка должна сравнивать несколько членов группы.

GREASE не даёт неверно назвать единичный сбой

GREASE ECH посылает правдоподобное расширение без реальной конфигурации, выявляя нетерпимые middlebox и прикрывая реальное использование. Поэтому один сбой расшифровки ещё не доказывает ошибку. Несогласованные retry-конфигурации, циклы между узлами и ech_required дают более точные сигналы.

Чего не доказывают RFC

Документы фиксируют формат, роли и модель угроз, но не распространённость, состояние конкретного браузера, резолвера или сети и не размер множества провайдера. Такие выводы требуют отдельного измерения.

Источники