Кратко

  • ECH превращает HTTPS/SVCB-запись в действующую криптографическую конфигурацию: опубликованный ключ полезен лишь тогда, когда достигнутый edge имеет соответствующий закрытый ключ.
  • Измерять нужно окно между первым появлением в DNS и готовностью всей сети, различая принятие, отказ, retry, безопасное отключение и жёсткий сбой.
  • Retry-конфигурация исправляет ограниченное рассогласование, но не доказывает атомарность публикации; постоянные повторы указывают на разные версии DNS, edge или backend.
  • Интегрированные платформы распределяют стоимость хранения, перекрытия и телеметрии. Multi-provider-схеме нужны переносимые квитанции версий и активации.

DNS раздаёт рабочее криптографическое состояние

RFC 9849 разделяет приватный ClientHelloInner и видимый ClientHelloOuter. Inner содержит настоящее имя сервера и чувствительные параметры; Outer несёт зашифрованную капсулу. Фронтальный сервер открывает её закрытым ключом, соответствующим ECHConfig клиента.

RFC 9848 задаёт публикацию параметра ech через DNS Service Binding, а RFC 9460 связывает endpoint и параметры в SVCB/HTTPS. DNS уже не только указывает адрес: он влияет на форму первого TLS-сообщения.

Порядок имеет цену. Если сначала активировать ключ везде, нужен период перекрытия. Если сначала публиковать DNS, клиент может попасть на edge без ключа. Сертификат и обычный HTTPS при этом работают; они не доказывают принятие ECH с первой попытки.

Четыре состояния в одной попытке

Браузер решает, предлагать ли ECH. Политика Chrome Enterprise указывает зависимость от поддержки сервера, HTTPS-записи и rollout. FAQ Firefox описывает включение по умолчанию с Firefox 119 и отключение предприятием, родительским контролем или доверенным middlebox.

Resolver определяет, что узнает браузер. RFC 9460 признаёт, что подавление SVCB лишает соответствующей защиты. Документация Cloudflare описывает подавление HTTPS-ответов и canary-домен как локальные средства, предупреждая о конфликте переписывания с DNSSEC.

Авторитетный DNS контролирует версию, TTL и aliases; edge контролирует закрытый ключ по группам. Нужная квитанция связывает hash ECHConfigList, config_id, первое наблюдение DNS, TTL, время ready каждой группы, принятие, retry и хвост старого cache.

Вторая удача не отменяет первый mismatch

Сервер может выдать retry-конфигурацию клиенту со старым ключом. Это полезное восстановление, но смысл прост: первая комбинация была непригодна и потребовала ещё одного соединения и задержки.

RFC 9849 рекомендует не принимать новую retry-конфигурацию для соединения, уже начатого из retry. Несколько несовместимых серверных конфигураций названы возможной ошибкой. Если каждое исправление объявляет следующую версию, у флота нет общей авторитетной версии.

Retry следует делить по версии, resolver, клиенту и edge. Короткий хвост плановой ротации может быть управляемым; устойчивый пик в одной точке — инцидент. Глобальное среднее умеет превращать целую неисправную группу в вежливое округление.

Анонимность тоже зависит от единообразия

ECH защищает SNI, но набор анонимности требует внешне похожих сервисов. Разные cookies HelloRetryRequest, имена ключей, порядок extensions или ошибки при определённых условиях способны выделить backend. Стандарты описывают этот механизм риска; пакет не измеряет сокращение набора анонимности в конкретном production-развёртывании.

RFC 9849 рассматривает это для split mode. RFC 9934 стандартизирует PEM с закрытым ключом и подходящим ECHConfigList. Формат решает обмен, не активацию. Корректный файл в controller не доказывает состояние edge.

RFC 9180 задаёт HPKE. Криптография может идеально защищать капсулу, зашифрованную для ключа, который последний edge ещё не получил. Это сбой change-процесса, не cipher.

Преимущество интегрированной платформы

Оператор DNS и edge может подготовить ключ, проверить группы, опубликовать, держать перекрытие, наблюдать retry и удалить старую версию внутри одной границы. Cloudflare документирует ECH по умолчанию для Free zones и настройку для других планов. Это не глобальная статистика успеха, а пример координации как свойства продукта.

Multi-CDN-домену приходится согласовывать общий ECHConfig, несколько service bindings или разные свойства по маршрутам. Хранение секретов, TTL, cache, rollback и доказательство ready становятся условиями поставщиков. Стандарт задаёт сообщения, но не синхронизирует change window.

Lock-in возникает, когда только внутренний graph поставщика показывает активную версию. Миграция переносит ключи и заново строит историю доверия. Экспортируемые hashes, времена, группы, принятие и rollback сохраняют выход.

Вывод о координационной премии и lock-in — аналитическое следствие разделённых поверхностей контроля, а не наблюдаемое состояние рынка. Владелец домена оплачивает планирование перекрытия и переносимость; DNS-провайдер — публикацию, TTL и cache evidence; edge-провайдер — распределение секрета, fleet telemetry и rollback; предприятие — тесты resolver policy и поддержку; пользователь — неудачную первую попытку и retry latency. Контракт перераспределяет деньги и труд, но не устраняет затраты.

Проверяемый критерий

Каждая ротация должна фиксировать hash, DNS-наблюдения, TTL, целевой edge, активацию, принятие первой попытки, retry, задержку, отключение, ошибки и rollback.

Тезис ослабевает, если DNS публикует лишь после готовности не менее 99,999% edge, mismatch ниже 0,01%, p99 retry ниже 25 мс, старые версии исчезают за TTL плюс 30 секунд, а multi-provider-переход даёт тот же результат без общей закрытой оркестрации. Он усиливается, если более 1% первых попыток требуют retry, группа расходится дольше двух TTL или rollback превышает 300 секунд.

Это будущие пороги опровержения, а не наблюдаемая статистика рынка. Точность нужна для теста, не для украшения неизвестности.