Кратко

  • Зашифрованный ClientHelloInner, внешняя оболочка и public_name сервера, обращённого к клиенту, — разные факты. Публичное имя не является именем частного backend.
  • DNS-конфигурация, принятие ECH, проверка TLS и успех приложения требуют самостоятельных свидетельств; один слой не может присвоить себе вывод другого.

RFC 9849 разделяет начало рукопожатия на две формы. Частные значения помещаются в ClientHelloInner, безобидные значения и расширение ECH — в ClientHelloOuter; внутреннее сообщение шифруется открытым ключом ECH. Дополнительные аутентифицированные данные связывают внутреннее и внешнее сообщения и ограничивают определённый класс подмены оболочки. Это не утверждение, что DNS-запись, публичный адрес, фронтальный оператор, backend и субъект приложения — одно лицо.

Смысл public_name уже, чем кажется. Это DNS-имя сервера, обращённого к клиенту, которому в модели ECH доверено обновлять конфигурацию и помогать при восстановлении после устаревшей конфигурации. Обычно оно помещается во внешний SNI. Это публичная поверхность маршрутизации и восстановления, а не скрытое имя origin, не доказательство владения и не результат проверки личности для всех закрытых имён.

Топологии показывают необходимость такого различения. В shared mode фронтальный сервер и TLS-терминатор могут быть одной стороной. В split mode фронтальный сервер передаёт соединение backend, который завершает TLS, не получая открытый текст на фронте. RFC предполагает аутентифицированный канал между ними и невозможность корреляции двух участков для атакующего; точный механизм против корреляции остаётся вне спецификации. Наблюдение ECH не проверяет эти предпосылки развертывания.

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

RFC 8446 оставляет TLS независимым от прикладного смысла: он согласует параметры, при необходимости аутентифицирует стороны и создаёт ключи. Якоря доверия и подробная проверка сертификата — отдельные решения. RFC 9460 разрешает SVCB/HTTPS передавать ключи и альтернативные конечные точки, которые могут иметь разных операторов и возможности. Одна DNS-запись говорит о возможной инструкции клиенту, но не о реально выбранном терминаторе и не о результате услуги.

В проверяемом журнале должны остаться отдельные поля для источника и TTL ECHConfig, резолвера и кэша, принятия/отклонения, ожидаемой идентичности и проверки, канала front-end/backend, выбранной точки и результата приложения. Зашифрованный пакет может заполнить одну колонку, но не остальные.

Источники