Назад | Перейти на главную страницу

Проблема с Captive Portal в Chrome на Android

Я установил WebAuth в нашем общедоступном Wi-Fi. У нас есть Cisco WLC 5508, и при использовании устройств iOS, Apple, Windows или некоторых устройств Android страница загружается правильно, однако, когда я использую устройство с Chrome 53.0.2785.124 в качестве браузера по умолчанию в Marshmallow 6.0.1, я получаю страница с ошибкой, указывающая на возможную атаку MTM. Он гласит: «Ваше соединение не является частным», за которым следует другой текст и NET :: ERR_CERT_COMMON_NAME_INVALID. Вот скриншот ошибки.

Насколько я понимаю, это связано с тем, что браузер пытается получить доступ к URL-адресу и ожидает определенного результата, однако сертификат на запрошенной домашней странице google.com не соответствует сертификату для хоста на возвращенном wlc.mydomain.com SSL-сертификат.

Один раздел www.google.com/chrome/browser/privacy/whitepaper.html гласит:

Если Chrome обнаруживает тайм-ауты SSL-соединения, ошибки сертификата или другие проблемы с сетью, которые могут быть вызваны перехватывающим порталом (например, сетью Wi-Fi отеля), Chrome отправит запрос без файлов cookie на http: // www.gstatic. com / generate_204 и проверьте код ответа. Если этот запрос перенаправлен, Chrome откроет цель перенаправления на новой вкладке при условии, что это страница входа. Запросы к странице обнаружения адаптивного портала не регистрируются.

Фактически он отправляет запрос на http: // connectivitycheck.android.com/generate_204. Проблема, которую я вижу, находится в ответе от WLC, код состояния - HTTP 1.1 200 OK. Я бы ожидал увидеть ошибку из-за блокировки страницы или ответ 300, указывающий на перенаправление. Судя по приведенному выше тексту от Google, похоже, что браузер перейдет в режим Captive Portal (и откроет новую вкладку для аутентификации), КОГДА он получит перенаправление.

Я думаю, это может быть проблема с конфигурацией WLC, но, возможно, это проблема с Chrome 53 на Android.

Если у кого-то есть рекомендуемое решение, я был бы признателен.

С уважением, D

Оказывается, это ошибка в Chrome.

См. Проблему 662150.

https://bugs.chromium.org/p/chromium/issues/detail?id=662150&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS% 20Modified & groupby = & sort =

Номер Umbrella - 335933.

****Обновить:

Нам это действительно нужно для работы. Google никуда не денется, чтобы найти решение. Мой новый S7E имеет встроенное приложение портала.

Я предполагаю, что у других производителей все еще будут проблемы. Я действительно видел, как один пациент пришел с планшетом Lenovo, который испытал это. У сотрудницы было то же самое с ее старым устройством Samsung.

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

Сначала я попробовал сбросить трафик ASA на основе полного доменного имени, но поскольку трафик исходит от WLC, я не мог отказать на основе VLAN.

Итак, взлом DNS.

На WLC я настраиваю 3 виртуальных интерфейса. 1 - внутренний. 2 - поставщик, 3 - общедоступный. У каждого есть своя собственная область действия DHCP, поэтому я могу установить все их конкретные параметры для их уникальной ситуации. 3 имеет WLAN с связанным с ней перехватывающим порталом.

Я настроил WLAN моего поставщика для использования общедоступных DNS-серверов - не очень много в этой WLAN.

У меня есть два публичных кэширующих DNS-сервера под управлением CentOS с BIND 9; Я заблокировал их, чтобы минимизировать поверхность атаки. Это виртуальные машины на хостах ESXi, на каждом из которых установлен медный сетевой адаптер, который подключается к изолированному виртуальному коммутатору и моей сети DMZ. Это не стоило мне ни цента.

Я сделал это, потому что некоторые пользователи (посещающие врачи) используют свои личные устройства, и мы подключаем их к поставщику без адаптивного портала (они подключаются один раз и остаются на связи - у гостя есть ограничение по времени, и он должен принять Политику допустимого использования).

Добавлен в /etc/ named.conf

zone "connectivitycheck.android.com" IN { type master; file "sinkhole.db"; };

zone "clients3.google.com" IN { type master; file "sinkhole.db"; };

/var/ named/sinkhole.db

$TTL 600 @ IN SOA localhost root ( 5 ; serial 3h ; refresh 1h ; retry 1w ; expire 1h ) ; min TTL ; IN NS ns. * IN A 127.0.0.1 connectivitycheck.android.com. IN A 127.0.0.1 clients3.google.com. IN A 127.0.0.1

Это не красиво, но очень хорошо работает. Надеюсь, это поможет кому-то другому.