Кратко

  • RFC 9540 определяет пустой параметр ohttp в записях SVCB или HTTPS, ресурс /.well-known/ohttp-gateway на том же хосте и получение ключевой конфигурации шлюза.
  • Механизм не обнаруживает и не удостоверяет ретранслятор; DNS-объявление, идентичность конечной точки, пригодный ключ и завершённый запрос дают разные свидетельства.
  • Уникальная конфигурация, редирект или dohpath способны выделить одного клиента даже при исправном шифровании, поэтому согласованность требует отдельной проверки.

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

Криптография сработала. При этом криптографический материал создал группу из одного участника.

Опубликованная в феврале 2024 года RFC 9540 стандартизирует обнаружение Oblivious HTTP через записи Service Binding. Она заменяет часть закрытой координации понятным путём к шлюзу и его ключам. Но документ не выдаёт обнаружение за результат приватности: разделы безопасности прямо описывают направленную выдачу ключей и путей. Для руководителя это означает, что рекламируемая возможность и подтверждённое свойство должны жить в разных строках контроля.

Пустое значение принимает непустое решение

SvcParamKey ohttp обязан иметь пустое значение и в текстовой записи, и на проводе. Само присутствие говорит, что описанный сервис можно использовать как цель OHTTP через связанный шлюз.

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

Свидетельство здесь узкое: конкретный DNS-источник в конкретное время, с данным TTL и правилами выбора объявил поддержку. Оно не доказывает, что клиент воспользовался OHTTP, шлюз был доступен или остальные получили те же данные. В незащищённом открытом DNS посредник может удалить SVCB-информацию и выполнить понижение. Проверка well-known-ресурса или сочетание шифрованного DNS с DNSSEC уменьшает риск, но ничего не говорит о последующем поведении шлюза.

Поэтому сохранять нужно исходный ответ, резолвер и точку наблюдения, TTL и возраст кэша, DNSSEC, транспорт, mandatory, кандидатов и мотив выбора. Флаг ohttp=true стирает и говорящего, и последствия его высказывания.

Ретранслятор остаётся за пределами обнаружения

OHTTP распределяет видимость между тремя ролями. Ретранслятор видит сетевую идентичность клиента и адрес шлюза, но не содержимое капсулы. Шлюз вскрывает капсулу, однако при надлежащем разделении не получает сетевую идентичность клиента из одной транзакции. Цель обрабатывает прикладной запрос.

RFC 9540 обнаруживает цель и шлюз. Поиск ретранслятора прямо вынесен за рамки. Предполагается, что клиент уже настроил доверенный ретранслятор, который способен обращаться к шлюзам или сообщать об их доступности.

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

Один well-known-адрес порождает два независимых маршрута

После обнаружения клиент использует /.well-known/ohttp-gateway на том же хосте, что и цель. Сервер может перенаправить этот ресурс. Однако клиент не должен передавать ретранслятору URI, полученный при загрузке ключей.

Иначе шлюз сможет встроить уникальное значение в редирект и узнать клиента, когда ретранслятор вернётся с тем же значением. Ретранслятор должен сам начать с well-known-ресурса и независимо пройти перенаправления. Общий для всех адрес допустимо кэшировать; персональный след наследовать нельзя.

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

Утечка может случиться до первой защищённой операции

Для инкапсуляции клиент сначала делает GET к шлюзу с Accept: application/ohttp-keys. При прямом запросе шлюз видит IP-адрес. Это может быть приемлемо, если задача состоит лишь в отвязке отдельных запросов от уже известного абонента. Но это расходится с обещанием скрывать местоположение и позволяет подобрать материал под наблюдаемый адрес.

Прокси скрывает IP, одновременно добавляя нового наблюдателя. Кроме того, сам ответ требует проверки. Конфигурация может быть синтаксически и криптографически верной, но уникальной. Поскольку OHTTP-запросы можно связать по использованной конфигурации, ключ A для одного клиента и ключ B для всех прочих образуют метку без взлома алгоритма.

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

dohpath способен стать именем

В oblivious DoH отдельной поверхностью служит dohpath. Уникальный путь идентифицирует клиента даже при общем ключе. Можно разрешать только заранее известное значение вроде /dns-query{?dns} или сверять произвольные значения с независимым источником. RFC допускает выборочные проверки по возможностям и модели угроз, но выборка даёт основание только для проверенной доли.

DDR и DNR также нельзя смешивать. В DDR сохраняются предусмотренные проверки сертификата обнаруженного резолвера. В DNR параметры могут прийти через DHCP или Router Advertisement, а доверие следует иной модели назначения. Ни один вариант сам по себе не исключает уникальный путь. Сертификат показывает владельца идентичности конечной точки, но не одинаковое отношение ко всем клиентам.

До заявления о приватности нужны девять квитанций

Управляемое внедрение раздельно фиксирует: публикацию ohttp; понимание mandatory; принятие источника DDR или DNR; идентичность конечной точки; получение разбираемой конфигурации; согласованность ключа, пути и редиректа; допустимость и доступность ретранслятора; завершение транзакции; и то свойство приватности, которое действительно поддержано наблюдениями.

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

Такое разделение не ослабляет OHTTP, а делает его подотчётным. Оператор может точно сказать, получил ли он доступность, развязку отдельных запросов или более широкую защиту идентичности. Объявление открывает проверяемую цепочку; опасным оно становится только в роли окончательного вердикта.

Источники