Пользовательская страница ошибок (deny_info) для HTTPS

У меня здесь, в моем squid.conf, есть следующие ACL с настраиваемым файлом «страницы ошибок» с именем ERR_TJS, расположенным в «/ usr / share / squid / errors / English»:

acl tjs_sites url_regex "/etc/squid/sites_regex.acl"
acl tjs_domains dstdomain "/etc/squid/domains.acl"
http_access deny tjs_sites
http_access deny tjs_domains
deny_info ERR_TJS tjs_sites
deny_info ERR_TJS tjs_domains

Специально для ACL-файл "/etc/squid/domains.acl", у меня есть следующие домены:

flyordie.com
www.flyordie.com
king.com
www.king.com
miniclip.com
www.miniclip.com
kongregate.com
www.kongregate.com
clashroyale.com
www.clashroyale.com
facebook.com
www.facebook.com
instagram.com
www.instagram.com
snapchat.com
www.snapchat.com

Проблема в том, что когда HTTPS-запрос выполняется к Squid, вместо того, чтобы давать настраиваемую страницу ошибки для " https: / /www.facebook.com ", например, показывает общую страницу с ошибкой, отправленную браузером, как эта из Mozilla Firefox:

Прокси-сервер отклоняет соединения

Firefox настроен на использование прокси-сервер, который отказывается подключаться.

Проверьте настройки прокси, чтобы убедиться, что они верны. Обратитесь к своему сетевому администратору, чтобы убедиться, что прокси-сервер работает.

Я нашел эту информацию в документации Squid:

Пользовательские страницы ошибок не отображаются для HTTPS

HTTPS использует сообщения HTTP CONNECT для ретрансляции через прокси. Из-за поведения браузера, обрабатывающего эти сообщения CONNECT (описанных в https://bugzilla.mozilla.org/show_bug.cgi?id=479880 ), любая настраиваемая страница ошибок, созданная прокси-сервером, игнорируется, а стандартная страница браузера вместо этого отображается.

Обычно на этой странице браузера упоминается сбой соединения или другие подобные нерелевантные детали.

Фактически любой ответ, кроме 200 OK, полностью отбрасывается браузером и отображается та же самая страница шаблона браузера. Это может привести к очень странным проблемам с аутентификацией при использовании HTTPS через аутентифицированный прокси, а также для схем аутентификации, где релевантно тело сообщения 407.

Я слышал, что с помощью Squid вы можете перехватывать некоторые "состояния" из HTTP / HTTPS-соединений. , например, обработка этих сообщений CONNECT ..

Мои вопросы: есть ли способ применить пользовательский deny_info , подобный этому, который у меня есть для запросов HTTPS, возможно, манипулируя этими сообщениями CONNECT, или любым другим способом? И как я могу этого добиться (пожалуйста, на каком-нибудь примере)?

1
задан 16 February 2017 в 01:33
1 ответ

Когда браузер настроен на использование прокси для HTTPS, он сначала пытается установить туннель CONNECT через прокси на удаленный сайт. Любой ответ HTTP от прокси-сервера, кроме «200 Tunnel Ready», игнорируется и приводит к ошибке «Прокси-сервер отклоняет соединение». Это можно исправить, сначала расшифровав соединение, а затем запретив доступ к нему в соответствии с настройками. См. Статью https://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html , в которой это более подробно описано.

1
ответ дан 3 December 2019 в 23:34

Теги

Похожие вопросы