Я настроил анонимный прокси-сервер squid, и он работает совершенно нормально, но я не нашел ничего о том, как зашифровать трафик между мной и самим сервером. Когда начать?
2 ответа
3
Документация 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 (спасибо Дэну за обновление).
Запуск локального (на том же компьютере, что и в браузере) stunnel в качестве прокси-оболочки будет решать эту проблему для любого браузера, но может не подходить для предполагаемого развертывания. Эта полезная страница показывает, как создать такую настройку (также с дополнительной аутентификацией PAM):
Обратите внимание, что это совершенно другое, чем использование stunnel для туннелирования через HTTP-прокси через CONNECT, это более часто документированный сценарий. Ваше решение, использующее SOCKS через SSH, в некоторых отношениях примерно эквивалентно, но у вас нет поддержки HTTP, оно не ограничено (например, ПОДКЛЮЧИТЕ к какому-либо порту), у вас нет кэширования, а аутентификация не обрабатывается браузером.
Если вы используете прокси-аутентификацию и хотите защитить заголовки учетных данных, это (HTTPS-соединение клиент-прокси) - хороший план. В противном случае эта настройка может не решить всех проблем, которые можно ожидать, и HTTPS-соединения становятся зашифрованными с двойным шифрованием, что (по крайней мере) дополнительно увеличивает задержку соединения.
- вы подключаетесь к HTTP-сайту: незашифрованный трафик все равно покидает прокси
- вы подключаетесь к HTTPS-сайту: в клиентском прокси-сервере нет ничего, что действительно требует шифрования, кроме цели запросов CONNECT (т. е. имени хоста веб-сайта), но у клиента TLS привет, вероятно, будет SNI, содержащий это имя, и сервер Привет почти наверняка будет иметь сертификат сервера, любой из которых может быть перехвачен
Другой случай, когда это добавило бы ценность, - это использование клиентских сертификатов для проверки подлинности прокси-сервера (но браузеры также не поддерживают это), сообщается, что это работает в Firefox (см. Ошибку 209312).
Эта проблема была недавно помечена CERT: Примечание об уязвимости VU # 905344 HTTP CONNECT и сообщения 407 Proxy Authentication Required не защищены целостностью в результате атаки FalseCONNECT MITM.
2
Я набираю здесь точную команду, которую я сейчас использую для настройки 2048-битного шифрования на прокси-сервере:
ssh -C2qTnN -D 8080 user@remote-address
в то время как настройки прокси вашего браузера (то же самое уродливое окно, которое выскакивает для настроек IE) должны указывать на 127.0.0.1:8080 для поля SOCKS, все остальные оставлены пустыми (как обычно говорят о прокси SOCKS)
Очевидно, что все остальные порты могут работать, если они открыты на удаленном сервере.