Кратко

  • HTTP 511 сообщает клиенту, что перед выходом в сеть нужно выполнить условие сети доступа. Его должен выдавать перехватывающий прокси, а не источник, указанный в запросе.
  • Ответ должен вести к отдельному ресурсу для входа, а не просить учётные данные в контексте адреса источника. Статус уменьшает путаницу, но не делает перехват доверенным и не устраняет проверку сертификата TLS.

Адрес назвал одного собеседника, ответил другой

После подключения к новой сети телефон продолжает обновлять погоду, календарь и программное обеспечение. До допуска сетевое оборудование может перехватить один из этих запросов и вернуть условия гостиницы или аэропорта. Человек иногда сразу узнаёт страницу Wi-Fi. Для фоновой программы это выглядит так, будто запрошенный сервис неожиданно прислал чужой HTML.

Суть конфликта — в полномочиях. URL называет источник, но байты сформировал посредник на пути. Браузер способен остановиться и попросить решения пользователя. Клиент API может попытаться разобрать страницу как данные, сохранить её, повторить запрос или последовать перенаправлению, так и не поняв, что автор ответа сменился.

RFC 6585 ввёл в 2012 году 511 Network Authentication Required, чтобы дать вмешательству отдельное имя. Статус означает: для сетевого доступа не выполнено предварительное условие. Не менее важен его предполагаемый отправитель — не запрошенный источник, а перехватывающий прокси, управляющий связностью.

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

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

Поэтому RFC 6585 указывает, что сервер-источник не должен генерировать 511. Для учётных данных и авторизации приложения уже существуют обычные механизмы HTTP. Статус 511 описывает условие пути и помогает клиенту понять, что исправление пароля приложения, вероятно, ничего не изменит.

Его доказательная сила невелика. Код способен указать на режим сетевого допуска, но не подтверждает законность требований, надёжность владельца портала или личность человека, использующего устройство.

Ссылка разделяет роли, форма смешивает их

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

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

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

Автоматические клиенты показывают реальную цену перехвата

RFC 6585 прямо называет 511 средством уменьшения ущерба от captive portal, особенно для агентов, которые не являются браузерами. Это не одобрение перехвата.

Программа обновления воспримет HTML вместо манифеста как повреждённые метаданные. Клиент синхронизации может зарегистрировать ложную ошибку WebDAV. Перенаправление не возвращает правильные полномочия: программа способна последовать ему и продолжить обработку вывода портала внутри прежнего сценария.

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

Кэш не должен переносить ограничение между сетями

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

Только действующая система контроля доступа может принять свежее решение. Кэш не уполномочен продлевать перехват.

TLS обнаруживает заимствованную идентичность

В открытом HTTP посредник способен заменить ответ и добавить 511. В HTTPS клиент сначала аутентифицирует имя сервера посредством TLS. У портала нет сертификата запрошенного источника, поэтому он не может честно завершить рукопожатие. RFC 6585 отмечает, что перехват HTTPS вызывает ошибку сертификата.

Значит, 511 нельзя получить после доверенного TLS-сеанса, который портал не мог установить. Подавление предупреждения ради страницы входа наделило бы сеть идентичностью источника — ровно той путаницей, которую статус старается ограничить.

Риски шире сертификатов. Посредник может увидеть данные аутентификации в открытом HTTP или вмешаться в cookie пространства имён источника. RFC подчёркивает, что captive portal создаёт такие угрозы с 511 и без него. Более точное сообщение об ошибке не превращает небезопасный путь в доверенный.

От неожиданной подмены к заранее объявленному состоянию

Captive Portal Architecture в RFC 8952 разделяет роли. Механизм подготовки сообщает пользовательскому устройству адрес API; API возвращает состояние; пользовательский портал проводит взаимодействие; устройство принудительного контроля блокирует или разрешает трафик. RFC 8908 задаёт обмен с API по HTTPS.

Теперь клиенту не обязательно отправлять открытую проверку постороннему источнику и обнаруживать ограничение по её подмене. При подключении он получает URI API, проверяет сертификат сервера и запрашивает собственное состояние. Ответ обязательно содержит логическое поле captive и при необходимости HTTPS-адрес пользовательского портала.

После действий пользователя клиент спрашивает снова, действительно ли ограничение снято. Успешная отправка формы или перенаправление сами по себе этого не доказывают. API и система контроля также должны подразумевать одно и то же пользовательское устройство.

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

Узкая истина, которую способен нести 511

511 не аутентифицирует портал, не узаконивает перехват, не обходит TLS и не доказывает согласие человека. Для источника это не замена 401 или 403. Его вклад точнее и скромнее: отнести требование допуска к сети и не дать ему выглядеть повторно используемым содержимым источника.

Последующая API-архитектура продолжает тот же принцип. Власть должна говорить под собственной идентичностью. Сеть вправе управлять пересылкой, но ей не нужно брать голос назначения, чтобы объяснить это управление.

Источники