Перенаправление пользователя на страницу заглушку ISP при https

Как вы понимаете ssl у нас куплен.

Что?

максимально эффективно без извращений.

Что вы под этим подразумеваете?

Укажите в web сервере который отдаёт вашу страницу загрузку по ssl fullchain файл ssl сертификата. Т.е. файл, в котором находится вся цепочка сертификатов, такой файл вам должен был предоставить удостоверяющий центр.

Если используется сертификат от letsencrypt, то это файл chain.pem.

Удачи.

1. У провайдера на странице-заглушке валидный SSL-сертификат, но когда браузер пользователя запрашивает сайт по https отдаётся сертификат не сайта (денег на счёте юзера нет), а провайдера. Проблема.

2.Например, чтобы при запросе любого стороннего ресурса перенаправляло на страницу заглушку, без подмены DNS (вроде она в данном случае не поможет) и прочих шаманств.

Просто задача интересная.

ок, Костя, обдумаю этот вариант.

Спасибо.

У провайдера на странице-заглушке валидный SSL-сертификат

Он валиден только для купленного домена, а не того, куда переходит на самом деле юзер. Задача в общем случае нерешаема, а частные решения вас в данном случае не устроят(свой CA, раскиданные на компьютеры пользователей, вот это вот всё)

А как, в теории, мог бы помочь fullchain?

С указанием на корневой сертификат CA.

Let's encrypt-овский - никак. Тут логика вот в чём(в общем случае, отбросим пока всякие HPKP) - корневые CA на клиенте считаются доверенными для выдачи сертификатов на любые сайты.

То есть предположим у тебя корпоративная среда. Ты распространяешь свой CA на клиенты(через Active Directory или еще как-нибудь). И потом просто отдаешь страницы с любого домена подписанные своим CA(как это делать - вопрос десятый). И клиенты считают что это окей.

В случае провайдера такая схема не взлетит, потому что доступа на компьютеры пользователей ты не имеешь - следовательно свой CA ты туда не внедришь. А ни один из CA, уже присутствующих на их компьютерах в списке доверенных не будет выписывать тебе сертификаты на любые непринадлежащие тебе домены.

Ну и заключительный совет - подтяни теорию по SSL/TLS - тогда таких вопросов возникать не будет. Ибо они изначально придумывались чтобы перехват(а редирект на свою страницу и/или выдача своего контента ВМЕСТО оригинально присутствующего на сайте - это перехват) был НЕВОЗМОЖЕН. Ну, за исключением случаев, когда сам пользователь жмет кнопку «да мне насрать»(и то - HSTS и этого не позволяет)

Ну и заключительный совет - подтяни теорию по SSL/TLS - тогда таких вопросов возникать не будет.

Это да, я ездил в санаторий, в Ялту смотрел лекции Яндекс.КИТ на эту тему.

Но лекции лекциями, а вот такая живая практика практикой :-)

Просто любой ISP, емнип, может показывать заглушку при запросе на https, только делает это по http.

Да и вообще, автору думаю посоветовать поискать как при нулевом балансе не пускать юзера дальше локалки прова. Это как раз, думаю, тривиальная задача.

Просто любой ISP, емнип, может показывать заглушку при запросе на https, только делает это по http.

Это не возможно, даже чтобы сделать редирект на http нужно всё-таки что-то отдать по https - а значит мы снова встреваем в проблему с сертификатами.

Предупреждаю вопросы: всякие sslstrip и mitmproxy которые так умеют полагаются в общем-то на то, что на клиенте есть свой CA - и дальше схема понятно.

Да и вообще, автору думаю посоветовать поискать как при нулевом балансе не пускать юзера дальше локалки прова. Это как раз, думаю, тривиальная задача.

Именно - вариантов проверенных времен тут достаточно. Самое верное тут - это ISG(не только Cisco-вский, можно и на том же accel-ppp напилить похожее).

Ну и отдавать по http(и только по http) заглушку «Денег нет, но вы держитесь»(L4 redirect в терминах ISG)

Никак! Логика!

Валидный кейс:
1. Запрашиваем сайт https://example.com.
2. По ssl возвращается сертефикат в котором указано доменное имя example.com и сам сертификат подписан удостоверяющим центром известным броузеру (какой-нибудь GoDaddy).
3. Броузер показывает зеленый заначек «secure connection» рядом со строкой адреса и загружает сайт.

Твой кейс:
Вариант 1:
1. Запрашиваем сайт https://example.com.
2. ISP прозрачно проксирует вызов на страницу загрузки https://isp.ru.
3. По инициированному со стороны пользователя ssl соединению передается валидный сертификат на домен isp.ru.
4. Броузер ожидает example.com, а ему по ssl возвращается сертификат на isp.ru, он показывает ошибку про подмену сертификата.

Вариант 2:
2. ISP пытается отдать по https код 302 и редирект на https://isp.ru.
3. По инициированному со стороны пользователя ssl соединению передается самоподписанный сертификат на example.com (если имя вытащили из SNI).
4. Броузер показывает ошибку про не удостоверенный сертификат.

Да уже понятно.

Но думалось — а вдруг. Тем более Гугл активно зомбирует подсознание «Скоро все будет на https!»

Отмечу, что подобную задачу пытались решить в Максиме-Телеком (компания, что обслуживает бесплатную wi-fi в московском транспорте). Но у них так и не получилось сделать прозрачный редирект на свою логин-форму при старте юзера на https-сайт.

Однако на android при подрубании к wifi с кнопкой входа, сам андройд говорит что типа зайдите на эту страницку для старта, видно есть какой то механизм

Можно описать подробнее и со скринами? )

Captive portal же

Браузер начинает ругаться что ssl сертификат принадлежит нашей заглушке а не https://ubuntu.com, ты жмякаешь «я понимаю риск» и вуаля ты на заглушке.

В мосметро такая фигня и все привыкли, так что не парься

Общая практика - либо самоподписанные сертификаты с руганью браузера, либо просто дроп всего, что не 80/tcp.

+1 именно это да в том же pfsense / nethserver все это есть