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

[scatman]

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

[Slava]

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

[scatman]

Не помогло.

[Slava]

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

[sunchi]

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

[alexK]

viewtopic.php?f=1&t=969#p4994

[sles]

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

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

Спасибо!

[asket]

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

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

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

[user_606]

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

[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]

"Возможно поможет 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]

Обход как выше мне представляется уж очень сильными костылями

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

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

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