Captive portal — сетевой сервис, требующий от подключившегося к Сети пользователя выполнить некоторые действия для получения доступа в Интернет. Обычно используется для взимания платы, аутентификации абонента либо показа рекламы. Впервые[1] описан специалистами Стэнфордского университета в 1999 году[2].

При попытке зайти на любой сайт с устройства, MAC-адреса которого captive portal не знает, http-запрос перенаправляется на стартовую страничку портала. Технически перенаправление делается либо с помощью искажённого ответа на DNS-запрос, либо средствами маршрутизатора. Как правило, в ответ на изначальный запрос приходит HTTP-ответ с кодом 302, но в 2012 году было предложено специально для таких случаев ввести код 511[3].

Поскольку сценарий работы с captive portal корректно себя ведёт только в браузере при обращении к не-https сайту, большинство современных клиентских операционных систем после подключения к сети выполняет проверку на его наличие:

  • Android, начиная с версии 4, через несколько секунд после подключения запрашивает с одного из серверов компании Google файл с названием generate_204 и, не получая в http-ответе кода 204, создает соответствующее уведомление, при нажатии на которое в браузере открывается captive portal.
  • Windows и Windows Phone используют сервис Network Connectivity Status Indicator, который запрашивает файл с сайта, принадлежащего Microsoft, ожидая получить предопределённое содержимое. В некоторых случаях сверяется с эталоном IP-адрес сайта, возвращаемый DNS-сервером. При обнаружении captive portal так же, как и в Android, формируется уведомление для пользователя[4].
  • iOS-устройства, так же, как Windows, запрашивают файл (с одного из нескольких сотен[5] принадлежащих Apple сайтов) и сверяют его содержимое. В случае обнаружения captive portal во всплывающем окне открывается Captive Network Assistant, представляющий собой браузер без поддержки HTTP cookies.

Многие системы Captive portal уязвимы для атак посредника[6]. Возможны проблемы с перенаправлением пользователей, подключающихся с устройств, не распознающих captive portal и открывающих сайты, форсирующие использование https (например, с включенной технологией HSTS). По данным разработчиков Chrome, около 5 % сообщений об ошибках SSL/TLS вызвано Captive порталами[7].

См. также

править

Примечания

править
  1. Haidong Xia, Jose Brustoloni. Detecting and Blocking Unauthorized Access in Wi-Fi Networks (англ.) // Networking 2004: Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications Third International IFIP-TC6 Networking Conference Athens, Greece, May 9–14, 2004 : Proceedings. — Springer Berlin Heidelberg, 2004. — P. 795-806. — ISBN 978-3-540-21959-0. — ISSN 0302-9743. — doi:10.1007/978-3-540-24693-0_65. Архивировано 4 марта 2016 года.
  2. Guido Appenzeller, Mema Roussopoulos, Mary Baker. User-Friendly Access Control for Public Network Ports (англ.) // INFOCOM '99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE. — 1999. — Vol. 2. — P. 699-707. — ISBN 0-7803-5417-6. — ISSN 0743-166X. — doi:10.1109/INFCOM.1999.751456. Архивировано 5 июля 2017 года.
  3. RFC 6585 Additional HTTP Status Codes April 2012 «6.1. The 511 Status Code and Captive Portals»
  4. Nathan Hinkle. Windows 7 Network Awareness: How Windows knows it has an internet connection (16 мая 2011). Дата обращения: 30 июля 2015. Архивировано 22 июля 2015 года.
  5. Readme for iOS 7 WebAuth on Cisco Wireless LAN Controller, Release 7.4 MR 2. Cisco (сентябрь 2013). Дата обращения: 30 июля 2015. Архивировано 20 ноября 2015 года.
  6. APAN Meetings | Asia Pacific Advanced Network (APAN). Дата обращения: 17 сентября 2015. Архивировано 4 марта 2016 года.
  7. Архивированная копия. Дата обращения: 17 сентября 2015. Архивировано 4 марта 2016 года.

Ссылки

править