Как зашифровать соединение с прокси-сервером squid

документация Squid ссылается на это: http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection

однако проблема, скорее всего, не в настройке Squid, а в поиске браузера, который работает правильно...

Chrome поддерживает HTTPS-прокси, но только через файл PAC автонастройки или параметр командной строки --proxy-server (см. http://dev.chromium.org/developers/design-documents/secure-web-proxy)

Firefox все еще "работает над этим", см.https://bugzilla.mozilla.org/show_bug.cgi?id=378637 (7 лет и подсчитывать). наконец, поддерживает это начиная с версии 33, (спасибо Dan за обновление).

запуск локального (на той же машине, что и браузер)stunnel как обертка прокси решит эту проблему для любого браузера, но может не подойти развертывание. Эта полезная страница показывает, как создать такую настройку (с дополнительной аутентификацией PAM также):

http://www.jeffyestrumskas.com/index.php/how-to-setup-a-secure-web-proxy-using-ssl-encryption-squid-caching-proxy-and-pam-authentication/

обратите внимание, что это совершенно другая вещь, чтобы использовать stunnel для туннелирования через HTTP прокси через CONNECT, это наиболее часто документированный сценарий. Ваше решение, использующее SOCKS через SSH, примерно эквивалентно в некоторых смыслах, но у вас нет поддержки HTTP, он неограничен (подумайте, подключитесь к любому порту), у вас нет кэширования, а аутентификация не обрабатывается браузером.

Если вы используете аутентификацию прокси и хотите защитить любые заголовки учетных данных ,это (соединение HTTPS клиент-прокси) является хорошим планом. В противном случае эта установка может не решить все проблемы, один надеется, что это делает, и HTTPS соединения становятся двойным шифрованием, который (по крайней мере) добавляет далее задержка соединения.

1. вы подключаетесь к HTTP сайту: незашифрованный трафик все равно покидает прокси
2. вы подключаетесь к сайту HTTPS: в клиентском прокси-сервере нет ничего, что действительно нуждается в шифровании, кроме цели запросов на подключение (т. е. имени хоста веб-сайта), но TLS client hello, вероятно, будет иметь SNI, содержащий это имя, и сервер hello почти наверняка будет иметь сертификат сервера, любой из которых может быть зашифрован. перехватил

еще один случай, когда это добавило бы значение, - использование клиентских сертификатов для аутентификации прокси (но браузеры это тоже не поддерживают), это работает в Firefox (см. ошибку 209312).

эта проблема была недавно отмечена сертификатом:уязвимость Примечание вю#905344 HTTP CONNECT и 407 Proxy Authentication необходимые сообщения не защищены от целостности в результате FalseCONNECT MITM атаки.