Кратко

  • RFC 9934 задаёт PEM-файл с нулём или одним закрытым ключом PKCS #8 и одной ECHConfigList; при наличии секрета ему должна соответствовать хотя бы одна публичная конфигурация списка.
  • Это проверка внутренней связности артефакта. Она не подтверждает активный набор сервера, значение DNS, возраст клиентского кэша, принятие ECH или конечный эффект для приватности.

Самая опасная запись в журнале ротации может быть совершенно правдивой: «ключ и конфигурация совпадают». Опасность появляется, когда эту локальную истину читают как описание всей системы. В тот же момент процесс мог держать прежний ключ, авторитетная зона — новую запись, рекурсивный резолвер — старую, а клиент — ещё одну конфигурацию, полученную до переключения. Ни один участник не обязан был лгать; их поколения просто разошлись.

RFC 9934 стандартизирует точку передачи между такими участниками. Разные TLS-библиотеки и системы управления ключами получают общий текстовый формат для материала ECH. Файл содержит ноль или один закрытый ключ, а затем ровно одну ECHConfigList. Если секрет присутствует, он идёт первым как PKCS #8 PrivateKey с меткой PRIVATE KEY. За ним следует блок ECHCONFIG: base64-представление того же двоичного списка, который может быть опубликован в HTTPS Resource Record.

Внутренний контракт проверяем. Закрытому ключу должна соответствовать хотя бы одна ECHConfig из списка; содержимое после списка рекомендуется игнорировать. Это позволяет валидатору установить форму файла, порядок блоков, успешность декодирования и конкретное криптографическое соответствие. Проверка не говорит, прочитал ли файл рабочий процесс, сработал ли reload, какой из нескольких файлов выбран и какой набор отправляется как retry_configs.

Возможность оставить закрытый ключ за пределами файла особенно ясно показывает границу полномочий. Публичный список разрешено переносить в DNS, а закрытый ключ из секретного файла публиковать нельзя. Следовательно, безопасная система не просто «синхронизирует ECH». Она строит два проекционных объекта одной генерации: защищённый для сервера и публичный для HTTPS/SVCB. У них должна быть общая несекретная идентичность, но разные маршруты, читатели и правила хранения.

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

RFC 7468 даёт дисциплину текстовых границ и меток, а RFC 4648 — основу кодирования base64. Однако успешное чтение формата не устанавливает круг реальных держателей секрета. Резервные копии, снимки дисков, агенты доставки, отладочные процедуры и аварийный доступ могут иметь больше практической власти, чем владелец, записанный в каталоге файлов.

Далее начинается время протокола. По RFC 9849 клиентский сервер должен учитывать не только текущие опубликованные конфигурации, но и прежние значения, которые клиенты способны хранить на протяжении DNS TTL или дольше. Если внутренний ClientHello удаётся расшифровать, ECH может быть принят и внутреннее рукопожатие продолжается. Если нет, сервер обрабатывает внешний ClientHello, отклоняет ECH и может выдать актуальные конфигурации для повторной попытки. Подтверждение принятия наблюдает клиент; отвергнутое соединение не используется как готовый канал прикладных данных.

Значит, ротация — это протокол перехода, а не команда замены. У создания ключа, доставки секретного файла, активации в процессе, авторитетной публикации, истечения рекурсивного кэша и клиентского повтора разные часы. Немедленное удаление старого секрета после изменения зоны наказывает корректно кэширующего клиента. Бессрочное хранение всех поколений увеличивает поверхность доступа и работу по пробной расшифровке. Нужны заявленная длительность перекрытия и критерий завершения.

Для проверки следует хранить не секрет, а соединяющие его следы: несекретный идентификатор поколения, хеш файла, результат парсинга, число и порядок блоков, совпадение, фактические права чтения, квитанции доставки и reload, хеш активного набора сервера, авторитетный RRSet, выборочные рекурсивные ответы и их возраст, увиденный клиентом список, config_id, предложение и принятие либо отказ ECH, хеш retry, проверку сертификата, Finished и безопасное прикладное наблюдение.

Даже полностью связанная ротация не превращает параметр ech в универсальное свидетельство приватности. RFC 9848 указывает на понижение при смешанном наборе ECH- и не-ECH-конечных точек посредством выборочной блокировки. Незашифрованный DNS, различимый IP-адрес, анализ трафика и малая группа анонимности продолжают раскрывать или сужать назначение. RFC 9460 стандартизирует поверхность Service Binding, но не видит память сервера и решение рукопожатия.

Принцип Running-Code Primacy у Heng Lu полезен здесь как ограничитель масштаба показаний. Парсер свидетельствует о прочитанных байтах. Сервер — о загруженном наборе. DNS-авторитет и резолвер — о своих представлениях. Клиент — о выбранной конфигурации и принятии. Прикладная проба — о последующем результате. Связь этих показаний создаёт доказательство; объявление одного из них абсолютной истиной разрушает его.

Minimum Initial Specification объясняет, почему формат не должен разрастаться в глобальную систему управления ключами. Общая переносимая оболочка решает задачу совместимости. Конкретные TTL, способы reload, хранение, наблюдение и политика приватности остаются местными решениями у тех, кто способен увидеть последствия и выполнить откат. Местная автономия, однако, означает и местную ответственность за доказуемость перехода.

Поэтому итоговый вопрос для руководителя звучит не «валиден ли файл?». Нужно узнать, какую публичную конфигурацию получила каждая значимая группа клиентов, какой защищённый ключ в тот момент был активен, что решил handshake и кто вправе подтвердить заявленный результат приватности.

Источники