Кратко

  • Обычный HTTP CONNECT указывает цель TCP-соединения, но не задаёт собственные источник и путь прокси-сервиса. Новый режим обозначает сервис шаблоном URI, а поток байтов переносит в сообщениях Capsule.
  • 30 октября IESG одобрила проект для публикации как Proposed Standard. Совместимым шлюзам придётся преобразовывать туннель между поддерживаемыми версиями HTTP; в открытых материалах нет ни числа внедрений, ни результатов работы в поле.

У прокси появился адрес. У шлюза появилась новая обязанность.

HTTP CONNECT давно позволяет клиенту попросить прокси открыть TCP-соединение с указанными хостом и портом. Затем прокси пересылает байты между клиентом и целью. Но запрос указывает лишь, куда должен вести туннель. Собственных пути и источника у самого прокси-сервиса нет.

Это неудобно, если один HTTP-сервер обслуживает несколько прокси-сервисов. Без отдельного пути или источника сервер не может различить их так, как различает веб-ресурсы или виртуальные хосты. В проекте описано и последствие для безопасности: без явного источника прокси обычные защиты от ошибочной переадресации на порт сервера применить сложнее, а область действия заголовков вроде Alt-Svc и Strict-Transport-Security становится неоднозначной.

30 октября IESG одобрила draft-ietf-httpbis-connect-tcp для публикации как Proposed Standard. Версия 17 вышла накануне. Проект предлагает новый способ переносить TCP через HTTP; он не определяет, к каким адресам пользователь вправе подключаться. У прокси появляется более ясный адрес, а разрешения по-прежнему задаёт его оператор.

Прокси-сервис обозначается шаблоном URI с переменными target_host и target_port. Клиент подставляет цель и отправляет прокси получившийся URI. В HTTP/1.1 это GET с последующим Upgrade до connect-tcp. В HTTP/2 и HTTP/3 используется Extended CONNECT, где :protocol имеет значение connect-tcp. В настройках прокси объявляется поддержка Extended CONNECT.

TCP-поток передаётся сообщениями Capsule Protocol. DATA несёт байты, а FINAL_DATA — последние байты и сигнал закрытия, эквивалентный TCP FIN. Границы капсул не изображают сегменты TCP или записи TLS. Это упаковка потока для передачи через HTTP.

Явные источник и путь дают прокси-сервису место в обычной модели HTTP. Один сервер может различать несколько сервисов; для заголовков, связанных с источником, появляется понятная область действия. Но правила доступа остаются отдельными. Прокси по-прежнему сам решает, какие цели разрешены. Шаблон URI не заменяет список разрешений.

Работа переходит к шлюзам. Совместимый шлюз должен поддержать HTTP/1.1 Upgrade или Extended CONNECT, передать connect-tcp и преобразовывать запросы между обслуживаемыми версиями HTTP. Через него должен проходить и Proxy-Status. Если целевой сервер проверяет клиентов по TLS-сертификатам, шлюз должен выполнить проверку сам или передать сведения о сертификате дальше.

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

Источники