Страница блокировки для https

Обсуждение программы редиректора
Ответить
scatman
Сообщения: 2
Зарегистрирован: Чт сен 01, 2016 14:13

Страница блокировки для https

Сообщение scatman »

Добрый день, всем!
Есть работающая система squid+Rejik с авторизацией в AD. Как сделать так, чтобы при обращении к блокируемому сайту по https выводилась подменная страничка, а не ошибка? Т.е. блокировка отрабатывает, не выводится подменная страничка.

Slava
Site Admin
Сообщения: 2251
Зарегистрирован: Пт апр 02, 2004 12:34
Контактная информация:

Re: Страница блокировки для https

Сообщение Slava »

пропишите урл в конфиге режика с кодом перехода:
url 302:http://ban.site.ru

scatman
Сообщения: 2
Зарегистрирован: Чт сен 01, 2016 14:13

Re: Страница блокировки для https

Сообщение scatman »

Не помогло. :(

Slava
Site Admin
Сообщения: 2251
Зарегистрирован: Пт апр 02, 2004 12:34
Контактная информация:

Re: Страница блокировки для https

Сообщение Slava »

Подтверждаю, https запрос не перенаправляется из за особенностей шифрованного соединения.
Возможно поможет ssl_bump, но я не проверял.

sunchi
Сообщения: 1
Зарегистрирован: Ср мар 01, 2017 13:38

Re: Страница блокировки для https

Сообщение sunchi »

Можете объяснить, каким образом https запрос тогда блокируется? Логика такая: шифрованное соединение и режик не может узнать УРЛ, но при этом, он ведь запрос то блокирует.
Значит он все таки узнает УРЛ. А если он узнает УРЛ, то почему не делает редирект? Спасибо

alexK
Сообщения: 17
Зарегистрирован: Чт ноя 27, 2014 14:52

Re: Страница блокировки для https

Сообщение alexK »


sles
Сообщения: 51
Зарегистрирован: Вт авг 10, 2004 9:34

Re: Страница блокировки для https

Сообщение sles »

Здравствуйте!

Не появилось ли какого-то работающего решения для выдачи странички блокировки https?

Спасибо!

asket
Сообщения: 40
Зарегистрирован: Вт янв 24, 2006 19:32
Откуда: Москва

Re: Страница блокировки для https

Сообщение asket »

Всем доброго дня.

Есть решение для отображения страницы блокировки для HTTPS. Моя конфигурация:
Debian 9, squid 3.5.23, прокси непрозрачный (прописан в браузере), SSL Bump, авторизация в AD.

Если у кого-то такая же ситуация и самостоятельно найти решение не удалось, то могу поделиться. С вариантом без SSL Bump не разбирался, т.к. оно мне не нужно.

user_606
Сообщения: 1
Зарегистрирован: Пт окт 19, 2018 10:00

Re: Страница блокировки для https

Сообщение user_606 »

Приветствую, интересно было бы почитать.

asket
Сообщения: 40
Зарегистрирован: Вт янв 24, 2006 19:32
Откуда: Москва

Re: Страница блокировки для https

Сообщение asket »

Попробую рассказать как удалось впихнуть невпихуемое.

Пусть есть секция какой-то блокировки и в url написано что-то вроде, -
url http://block.ru/block.html

Открываем в браузере блокируемый https урл, режик его меняет, но подмена делается некорректно. Видим:

невозможно открыть https://http/*

(именно так выглядит подмена, выполняемая на первом этапе создания https-подключения)
Причина такой некорректрой замены в том, что первое соедение идет без протокола http/https,
как CONNECT vk.com:443, режик при парсинге запроса в качестве протокола ставит none, результат замены я уже показал. Чтобы обойти фазу с отсутствующим протоколом нужно создать первую секцию замены
(прописать свою сеть)

<SSL>
work_ip 10.0.0.0/8
ban_dir /usr/local/rejik3/banlists/ssl
action pass

в pcre прописать строку

^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])\:443$

после чего замена урла начинает производиться когда в нем появляется протокол с которым режик делает замену правильно.

Теперь появляется новая ошибка, squid сообщает, что в данный момент запрос

http://block.ru/block.html не может быть выполнен (302 не помогает).

Обмануть squid удалось следующим образом. Нужно направить squid на промежуточный сайт с редиректом, я его сделал на localhost

url http://127.0.0.1/block.html

сайт пустой, в .htaccess прописано (использовался apache2)

Redirect permanent /block.html http://block.ru/block.html

Однако и в этом случае squid скажет, что в данный момент не может выполнить запрос, только на этот раз

http://127.0.0.1/block.html

Оказалось, что если результат такого запроса будет в кэше сквида, то он его откроет, для это достаточно выполнить

export http_proxy=http://127.0.0.1:3128
wget -q 127.0.0.1/block.html

и страница подмены начинает отображаться для http/https.

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

Не уверен, что это единственно правильное решение, но оно работает.

sles
Сообщения: 51
Зарегистрирован: Вт авг 10, 2004 9:34

Re: Страница блокировки для https

Сообщение sles »

"Возможно поможет ssl_bump"

могу сказать, что не помогает, и вот почему-
в документации написано, что надо указывать протокол в перенаправлении, например
url http://192.168.1.1/nelza.html

в этом случае , если ssl переламывается, в броузере ( пробовал в фирефоксе) наблюдаем:

При получении URL https://http/* произошла следующая ошибка

Невозможно определить IP-адрес по имени узла "http"

т.е. http воспринимается как часть имени.


собственно, если написать https, то картина та же:
При получении URL https://https/* произошла следующая ошибка

Невозможно определить IP-адрес по имени узла "https"



если же прописать https, то всё равно всё плохо:

При получении URL https://proxy/ban/porno.html/* произошла следующая ошибка

Невозможно определить IP-адрес по имени узла "proxy/ban/porno.html"

Ну собственно ровно то же, что выше описано.

Любопытно, можно что-то с таким сделать? Обход как выше мне представляется уж очень сильными костылями :-)

Спасибо!

asket
Сообщения: 40
Зарегистрирован: Вт янв 24, 2006 19:32
Откуда: Москва

Re: Страница блокировки для https

Сообщение asket »

Обход как выше мне представляется уж очень сильными костылями
Основная цель HTTPS протокола - обеспечить безопасное подключение клиента к веб-серверу. Подмена урла в этом подключении не может пройти легко, и браузер и сквид защищаются от таких подмен.
Поиск решения занял несколько дней, вначале дебажили режик, правили его код и т.д. но все оказалось несложно, когда знаешь, что делать, достаточно 15-20 минут на внедрение.

"Костыли" уже полгода успешно работают на прокси с 7-8 млн. запросов в день.

Попытки редиректа https на непрозрачном прокси без ssl bump и на прозрачном, но с ssl bump оказались безуспешными, в этих случаях найти решения для ошибок браузера и сквида не удалось.

Ответить