Хочу поделиться своим опытом обхода ошибок HSTS, которые мешают работе captive portal.
Моя конфигурация:
Controller версия 5.5.20
AC-Lite (3.8.14), AC-LR (3.8.14), AC-HD (3.8.6)
XG-16 (3.8.6)
Guest Control:
External Portal Server <IP Address>
Снять галочку с Secure Portal
Снять галочку с Redirect using hostname
Поставить галочку Enable HTTPS Redirection
Доступ до авторизации:
<Controller IP>
<Captive Portal Server IP>
<DNS Server IP>
**ВАЖНО: здесь должны быть DNS-серверы, которые DHCP выдает клиентам гостьевой сети.**
Беспроводная сеть:
WPA Personal
Поставить галочку Apply Guest Policies
Для моего внешнего captive portal я использую PacketFence 7.3.0 в режиме Web Auth.
Подключил аутентификацию captive portal к Active Directory и настроил PacketFence в обычном HTTP-режиме (не HTTPS).
Теперь любой, кто подключается к моей гостевой сети (с простым паролем, который я им даю), и у кого есть учётные данные в Active Directory, может попасть на captive portal и пройти аутентификацию.
Почему это важно:
Многие сайты сейчас строго требуют HSTS, из-за чего безопасные captive portals не загружаются, когда пользователь пытается перейти на сайт с включённым HSTS, например google или facebook.
Браузер считает редирект атакой типа «человек посередине» и отказывает в доступе к порталу.
Переключившись на незащищённый HTTP-портал (и включив Enable HTTPS redirection), я обеспечиваю корректное перенаправление всех HTTP и HTTPS-запросов клиента на captive portal без ошибок.
Поскольку я использую защищённую сеть WPA, даже без TLS на captive portal, трафик по Wi-Fi шифруется, и никто не сможет перехватить учётные данные, которые клиент вводит на captive portal (кроме тех, кто уже получил доступ к защищённой сети — например, взломав пароль или получив его другим способом).
Конечно, это никогда не будет лучшим решением — передавать любые учётные данные по незащищённому соединению. Но учитывая, что HSTS фактически ломает работу защищённых captive portal, это показалось мне самым приемлемым вариантом.
Надеюсь, мой опыт будет полезен тем, кто столкнётся с проблемами из-за HSTS.
Моя конфигурация:
Controller версия 5.5.20
AC-Lite (3.8.14), AC-LR (3.8.14), AC-HD (3.8.6)
XG-16 (3.8.6)
Guest Control:
External Portal Server <IP Address>
Снять галочку с Secure Portal
Снять галочку с Redirect using hostname
Поставить галочку Enable HTTPS Redirection
Доступ до авторизации:
<Controller IP>
<Captive Portal Server IP>
<DNS Server IP>
**ВАЖНО: здесь должны быть DNS-серверы, которые DHCP выдает клиентам гостьевой сети.**
Беспроводная сеть:
WPA Personal
Поставить галочку Apply Guest Policies
Для моего внешнего captive portal я использую PacketFence 7.3.0 в режиме Web Auth.
Подключил аутентификацию captive portal к Active Directory и настроил PacketFence в обычном HTTP-режиме (не HTTPS).
Теперь любой, кто подключается к моей гостевой сети (с простым паролем, который я им даю), и у кого есть учётные данные в Active Directory, может попасть на captive portal и пройти аутентификацию.
Почему это важно:
Многие сайты сейчас строго требуют HSTS, из-за чего безопасные captive portals не загружаются, когда пользователь пытается перейти на сайт с включённым HSTS, например google или facebook.
Браузер считает редирект атакой типа «человек посередине» и отказывает в доступе к порталу.
Переключившись на незащищённый HTTP-портал (и включив Enable HTTPS redirection), я обеспечиваю корректное перенаправление всех HTTP и HTTPS-запросов клиента на captive portal без ошибок.
Поскольку я использую защищённую сеть WPA, даже без TLS на captive portal, трафик по Wi-Fi шифруется, и никто не сможет перехватить учётные данные, которые клиент вводит на captive portal (кроме тех, кто уже получил доступ к защищённой сети — например, взломав пароль или получив его другим способом).
Конечно, это никогда не будет лучшим решением — передавать любые учётные данные по незащищённому соединению. Но учитывая, что HSTS фактически ломает работу защищённых captive portal, это показалось мне самым приемлемым вариантом.
Надеюсь, мой опыт будет полезен тем, кто столкнётся с проблемами из-за HSTS.