HotSpot перенаправляет https, и в браузере появляется ошибка SSL.

Я знаю, эта тема уже давно обсуждается. У меня та же проблема с перенаправлением на https на хотспоте. Сегодня утром я немного поразбирался. Создал свой собственный сертификат и установил его на хотспот. Он действительно обнаруживал и перенаправлял неавторизованных пользователей. НО большинство браузеров всё равно показывали предупреждение о неправильном имени домена (к тому же ещё и предупреждение о самоподписанном сертификате). В конце концов, как вообще можно создать сертификат на *? Это просто невозможно. Современные браузеры стали куда умнее в вопросах принятия сертификатов. К тому же, всё больше сайтов требуют https (например, Google и Facebook). Сомневаюсь, что здесь есть простое решение. Мне кажется, это скорее проблема браузеров и популярных сайтов, чем Mikrotik.

Если я правильно помню, Squid может генерировать HTTPS-сертификаты «на лету» для нужных доменов.

Было бы здорово =)

Привет, друзья, у меня версия 2011 v6.13, и нет перенаправления с HTTPS на страницу входа. Раньше у меня был такой же роутер с предупреждением SSL, но сейчас перенаправления нет. Может, кто-то поможет? Предупреждение SSL меня не беспокоит, большое спасибо!

Решения нет. Единственным решением было бы установить SSL-сертификат для IP точки доступа, а не для DNS. Проблема в том, что невозможно купить сертификат для локального IP. Можно создать сертификат для IP вашей точки доступа с помощью команд Linux или Mikrotik, но это будет недоверенный сертификат, и появится предупреждающее сообщение.

Это по замыслу сделать нельзя. Система сертификатов устроена так, чтобы не допускать перехват трафика, который должен идти на facebook.com, без предупреждения. Единственный способ перехватить такой трафик без предупреждения в браузере — создать новый сертификат для facebook.com. Этот сертификат должен быть подписан центром сертификации, установленным в браузере пользователя. Значит, собственный CA не поможет, потому что у пользователя нет сертификата вашего центра сертификации в браузере или на компьютере. Потом нужно загрузить новый сертификат facebook.com в вашу точку доступа и повторять эти шаги для каждого домена в интернете! И даже тогда некоторые браузеры могут предупреждать пользователя из-за certificate pinning. Вам придется устроить атаку типа "человек посередине" (MITM) на своих пользователей, а именно это и пытается предотвратить система сертификатов.

Все коммерческие решения, которые заявляют, что могут перехватывать любой SSL/TLS трафик, работают с CA, принадлежащим компании, где администратор компании может устанавливать корневой сертификат в хранилище доверенных на всех компьютерах компании. Ни один провайдер для своих пользователей такого сделать не может. И я бы первым расторг договор, если поймаю своего провайдера на MITM-атаке на https-сайты.

Мой совет: просто блокируйте https для неавторизованных пользователей. Используйте tcp reset, чтобы браузеры быстро получали отказ. Тогда пользователи попробуют другой (http) сайт и увидят страницы вашей точки доступа. Люди не жалуются, что у них не работают почтовые или rss-клиенты, пока не зайдут через http для входа — так почему это должно быть проблемой для https-сайтов?

Привет, ты решил эту проблему? Я пытаюсь найти решение, но пока ничего. Ты абсолютно прав. Может показаться смешным, но большинство пользователей реально не знают, что такое адресная строка! Буду признателен, если сообщишь, когда найдёшь выход, я тоже так сделаю!

В правилах файрвола используйте действие «reject» вместо «drop». «Drop» означает молча отбросить пакет, не отправляя никакого уведомления источнику запроса. «Reject» означает явно сообщить источнику, что этот пакет не разрешен. Это происходит уже слишком поздно в процессе. На этом этапе (при отправке ответа) браузер уже сравнил имя в сертификате с доменом, который пользователь ввёл в адресной строке, потому что браузер должен убедиться, что он подключается к правильному серверу. Большинство хотспотов не используют HTTP-перенаправления, а применяют возможности файрвола, чтобы отклонять или сбрасывать все IP-пакеты, а IP-пакеты к TCP-порту 80 перенаправляются файрволом на какой-то внутренний сервер. К этому моменту запрошенный домен уже сохранён для сравнения имени в DNS браузером и будет сверяться с именем сертификата внутреннего HTTP-сервера. Хотспот может знать запрошенное DNS-имя (если он отслеживает DNS-запросы), но, как я писал 2 марта, в этом случае хотспот должен генерировать сертификаты для каждого возможного (запрошенного) домена на лету и подписывать их у центра сертификации (CA), которому доверяет компьютер пользователя. Без возможности вмешательства в компьютер пользователя этого не сделать.