Кратко

  • draft-ietf-httpapi-privacy-06 фиксирует границу до ответа 3xx: ключ, Cookie или bearer token может покинуть клиента в первом незашифрованном запросе.
  • HSTS, HTTPS-запись DNS, закрытый порт 80, ограничение самой учётной записи и режим HTTPS-only работают в разные моменты. Конечный защищённый URL не доказывает безопасность начала.
  • Получив секрет по HTTP, сервер должен одинаково отказать любому значению, оценить раскрытие и решить вопрос отзыва. Проект одобрен IESG и находится в очереди RFC Editor, но 1 октября 2026 года ещё не был RFC.

Иногда опасный дефект не ломает интеграцию, а делает её удивительно устойчивой.

В конфигурации остаётся http://. Библиотека добавляет заголовок авторизации, отправляет запрос, получает перенаправление, устанавливает TLS и повторяет. Бизнес-операция проходит. Именно поэтому никто не замечает, что первая копия секрета уже пересекла сеть открыто.

Редакция 06 требует не путать события местами. Перенаправление — ответ на уже отправленный запрос. Второе соединение может быть безупречным, но оно не меняет историю первого.

Успешность маскирует потерю конфиденциальности

Для страницы, открываемой человеком, переход с HTTP на HTTPS часто служит удобным мостом. Программный клиент уже имеет полный URI и переносит повторно используемое полномочие. Ему полезнее громко остановиться до отправки, чем незаметно исправить ошибочную схему.

Полевое исследование мая 2024 года, послужившее толчком проекту, началось с пропущенной буквы и проверило ряд известных сервисов. Эти результаты — исторический снимок, а не нынешний реестр поставщиков; часть поведения изменилась. Механизм остаётся: нормальный ответ способен скрывать открытый первый запрос.

Поэтому нужны отдельные квитанции. Настроенный URI отражает намерение. DNS и HTTPS RR — обнаружение. Состояние HSTS — ранее сохранённую политику. Первый сетевой обмен — фактически вышедшие байты. 3xx или 403 — реакцию ответившей стороны. Следующий TLS-сеанс — только новый канал. Отзыв, авторизация и commit описывают последующие решения.

Защита должна успеть до первого запроса

HSTS из RFC 6797 позволяет хосту потребовать безопасные будущие соединения. Политика узнаётся по предыдущему HTTPS-сеансу и должна храниться клиентом. Заголовок на сервере не означает, что конкретный API SDK ведёт HSTS-состояние как браузер.

HTTPS-запись из RFC 9460 переносит сигнал в фазу выбора соединения. Клиент обязан запросить и истолковать его, а контролирующий путь или DNS противник может скрыть ответ от нового клиента. Совместное применение снижает риск, но не создаёт ретроспективной гарантии.

Закрытый порт 80 не позволит настоящему серверу получить там секрет. Активный противник всё ещё способен изобразить отсутствующую HTTP-службу. Поэтому окончательный инвариант остаётся у клиента: не присоединять секрет до выбора безопасного транспорта.

Ограничение может содержаться и в учётных данных. Атрибут Secure по RFC 6265 запрещает Cookie в небезопасном контексте. Схема secret-token из RFC 8959 передаёт ожидаемый способ использования. Произвольный заголовок API-ключа не получает такую политику от одного имени.

403 начинает расследование, а не отменяет событие

Если HTTP приходится оставить, проект рекомендует одинаковый 403 для любого небезопасного запроса с учётными данными, действительными или нет. RFC 9110 допускает отказ по причине, не связанной с достаточностью данных. Различие кода, текста или времени превратило бы endpoint в средство проверки кандидатов.

Сам отказ не возвращает секрет. Напрямую переданный API key или bearer token — копируемая власть, поэтому его следует считать потенциально скомпрометированным. Подпись или MAC может раскрыть лишь производное значение; тогда отдельно проверяются nonce, охват, привязка и повтор.

Автоматический отзыв тоже можно атаковать. Поток угаданных значений по HTTP способен случайно поразить действительный ключ и отключить его. Ограничения соединений и частоты, уведомление, карантин и управляемый период должны входить в политику. Это не превращает раскрытый bearer token обратно в безопасный.

Статус документа не равен статусу внедрения

Datatracker относит документ к рабочей группе HTTPAPI и целевому статусу Best Current Practice. История показывает одобрение IESG и переход в RFC Editor Queue 5 июня 2026 года. На 1 октября это всё ещё редакция 06 от 11 мая без номера RFC.

Такой путь доказывает проверку текста, не поведение установленной библиотеки. В shepherd-материалах отмечено отсутствие конкретных отчётов о реализациях. Рабочий репозиторий показывает развитие проекта, но не первый пакет холодного клиента.

RFC 7258 называет массовое наблюдение атакой. Даже запрос без ключа раскрывает путь, идентификаторы и намерение. С bearer token наблюдение может стать возможностью действовать.

Журнал в порядке событий на проводе

Следует хранить точный base URI, библиотеку и версию, режим перенаправления, момент добавления секрета, отдельное разрешение небезопасного режима, DNS и HTTPS RR, происхождение и возраст HSTS, реальные схему/адрес/порт/peer первого соединения, класс учётных данных без самого секрета, первый status и Location, TLS-peer повторения, оценку раскрытия, карантин/ротацию/отзыв и их распространение, авторизацию, commit ID и наблюдаемый эффект.

Неизвестность нельзя превращать в успех: hsts=none, https_rr=unavailable, exposure=possible, revocation=pending. Последний HTTPS-span не должен затирать первый HTTP-span.

Minimum Initial Specification поддерживает узкое общее правило: никакого повторно используемого секрета в небезопасном транспорте. Running-Code Primacy требует смотреть на реально вышедшие первые байты. The Policy Mirror обнаруживает власть значений SDK по умолчанию. Reality Layers разделяет настройку, обнаружение, раскрытие, ответ, авторизацию и эффект.

Источники