LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


0

1

Задачка с фриланса, говорю сразу.

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

Схема следующая: есть биллинг который проверяет баланс и отправляет юзера в ipset дальше начинает работать цепочка iptables в который ми закрываем весь мир кроме нашых dns ну и самой страничке-заглушки. Дальше тем же iptables делаем редирект: все что идёт на порт 80 и 443 отправляем на заглушку порты 8083 и 8443 соответственно.

С 80 портом проблем нет. Начинаются танцы с 443. Что происходит: идет запрос к примеру на https://ubuntu.com приведенная выше схема отрабатывает нас кидает на заглушку но! Браузер начинает ругаться что ssl сертификат принадлежит нашей заглушке а не https://ubuntu.com, ты жмякаешь «я понимаю риск» и вуаля ты на заглушке. Как вы понимаете ssl у нас куплен.

★★★★★

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

Что?

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

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

Tanger ★★★★★ ()

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

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

Удачи.

kostik87 ★★★★★ ()
Ответ на: комментарий от Tanger

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

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

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

Twissel ★★★★★ ()
Ответ на: комментарий от Twissel

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Twissel

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

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

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

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

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

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

Twissel ★★★★★ ()
Ответ на: комментарий от Twissel

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

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

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

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

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)

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

Валидный кейс:
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. Броузер показывает ошибку про не удостоверенный сертификат.

anonymous ()
Ответ на: комментарий от anonymous

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

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

Twissel ★★★★★ ()
Последнее исправление: Twissel (всего исправлений: 1)

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

Deleted ()
Ответ на: комментарий от Deleted

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

pinachet ★★★★★ ()

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

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

Deleted ()

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

deadNightTiger ★★★★★ ()
Ответ на: комментарий от Deleted

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

pinachet ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.