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

Ошибки SSL-сертификата в Captive Portals

Ситуация: Гости отеля пытаются получить доступ в Интернет через наш закрытый портал. Проблема: Google, Yahoo и теперь все больше и больше сайтов перенаправляют все домашние страницы на HTTPS, поэтому гость получает ошибку сертификата, когда мы перенаправляем их на нашу страницу входа в систему. Цените цель SSL - делать именно это, но задайтесь вопросом, есть ли другой способ управлять процессом подтверждения гостевого входа в систему, чтобы подтвердить свою личность, прежде чем разрешить доступ через брандмауэр. Это пугают гостей, которые не понимают. В основном нужна другая архитектура для процесса аутентификации / захвата портала и интересно, какие мысли у кого-то. Спасибо.

Все определение «переадресованного портала» вращается вокруг «перенаправления пользователя без его / ее ведома», что как раз одна из вещей, которых SSL был создан, чтобы избежать.

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

Проект Chromium имеет хорошая страница, описывающая, как работает их логика для обнаружения скрытых порталов:

  1. Попытка подключиться (простой HTTP) к известному хосту + URI
  2. Ожидать HTTP 204 No Content
  3. Если получен другой ответ, предположите, что это скрытый портал.

В предоставленной ссылке есть и другие подробности относительно того, как они обрабатывают сбои DNS при попытке разрешить известный хост и т. Д. Это только один пример, но (по моему личному опыту) современные конструкции ОС используют процессы, подобные этому, для обнаружения и запрашивать у пользователя даже, в некоторых случаях, до того, как пользователь откроет браузер. (Рассмотрим: кого-то, кто хочет использовать только IMAP-клиент или другую службу, отличную от HTTP.) В этом случае происходит обнаружение не через SSL / TLS, чтобы избежать беспокойства.

RFC 6585, раздел 6 предлагает новый код статуса HTTP 511 Network Authentication Required это не помогает в вашем случае с SSL / TLS, но является еще одним стандартом, который вы можете рассмотреть, если еще не используете его.

В любом случае, если пользователи получают ошибку сертификата, это связано с тем, что Сертификат не соответствует Имя хоста сайта.

В вашем случае это означает, что вы перенаправляете пользователей на свой портал без изменения URL-адреса. Пользователи видят "http://www.google.com"в адресной строке, но ваш портал на экране. Очевидно, они не совпадают, как и сертификат.

Вам нужно перенаправить их по HTTP (до перехода по HTTPS) на ваш портал адрес (или имя сервера), попросите их войти в систему, а затем перенаправьте их снова в предполагаемое место назначения, которое будет соответствовать правильно.

Видеть https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx как это сделать с кодами HTTP 3xx, особенно 303.

временное решение - помочь пользователям начать URL, начинающийся с «http», только после подключения сигналов Wi-Fi.

но, к сожалению, пользователям это не нравится. они говорят: "какой у вас сложный Wi-Fi"