Я хочу заблокировать определенные URL-адреса для некоторых пользователей моей внутренней сети. Для этой цели я использую явный прокси на основе squid с программой redirect_program. Клиенты настроены на использование pac-файла для URL-адресов https, что заставляет их направлять свои https-запросы на явный прокси-сервер.
Проблема в том, что перенаправление любого запроса CONNECT для URL-адреса https на URL-адрес заблокированной страницы не выполняется. Я пробовал URL-адреса заблокированных страниц на основе http и https, но мне не повезло. По некоторым причинам я не хочу использовать прозрачный прокси с ssl bumping.
Safari выдает ошибку «Safari не может открыть страницу. Ошибка: «Не удалось установить безопасный туннель через веб-прокси-сервер».
Chrome выдает ошибку «Эта веб-страница недоступна. ERR_TUNNEL_CONNECTION_FAILED '.
Вот строка из access.log для https://www.yahoo.com.
07 / Oct / 2015: 01: 41: 29 -0500 74 172.0.0.9 TCP_REDIRECT / 302 253 CONNECT www.yahoo.com:443 - HIER_NONE / - -
Я где-то читал, что браузер ожидает начать квитирование SSL / TLS после запроса на соединение, и поэтому он терпит неудачу. Вот цитата из документации по редиректору squid.
«Изменение URL-адреса и, в частности, перенаправление возможно только для определенных методов, а некоторые, такие как POST и CONNECT, требуют особой осторожности».
Это не говорит о том, что перенаправление невозможно для метода CONNECT. Однако нигде не упоминается, как мы можем перенаправить POST и CONNECT (меня особенно интересует CONNECT) или какой-либо пример.
Пожалуйста, расскажите мне, как перенаправить запросы на соединение https на заблокированную страницу. Если это невозможно, можно ли обойти это с помощью явного прокси? Спасибо.
Я использую squid 3.5.4 на ubuntu.
К сожалению, это невозможно без предварительной обработки (дешифрования) SSL-соединения. Браузеры по своей конструкции запрещают любую дополнительную полезную нагрузку / перенаправление из неудачных запросов CONNECT. Для более формального описания см. - http://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html.
если ты делать решите выполнить расшифровку SSL, тогда можно сначала позволить запросу CONNECT быть успешным, а затем заблокировать / перенаправить следующий HTTP-запрос, проходящий через этот установленный туннель подключения - пожалуйста, примите во внимание, что если это может быть даже не HTTP, поскольку некоторые приложения используют туннелирование прокси CONNECT для собственные протоколы (например, Skype).
Также следует иметь в виду - если приложение использовало технику «SSL-закрепления» при выполнении запросов CONNECT к прокси, оно откажется работать с расшифрованными соединениями.