Перенаправление выбранных HTTP-запросов из Squid на HTTPS
Возвращайте клиентское перенаправление для известных сайтов с поддержкой HTTPS вместо того, чтобы молча менять каждый исходный HTTP URL или предполагать, что прокси может создать поддержку TLS на источнике.
Squid может попросить браузер повторить выбранный HTTP URL через HTTPS. Назначение уже должно предоставлять соответствующий ресурс через HTTPS; запуск Squid на Raspberry Pi не создаёт эту возможность на сайте.
Для интерфейса url_rewrite_program в Squid 7 helper может вернуть клиентское перенаправление, например:
OK status=307 url="https://www.example.com/help"Это один иллюстративный ответ helper для подходящего запроса, а не полная программа helper. Браузер получает перенаправление и делает новый запрос к HTTPS URL. URL вне политики обновления может получить OK и остаться без изменений.
Используйте известный список назначений с поддержкой HTTPS и разбирайте входящий URL. Сохраняйте предполагаемый путь и query, учитывайте явные порты и осознанно обрабатывайте методы запроса. Слепая замена каждого префикса http предполагает, что у каждого источника есть эквивалентная служба HTTPS.
Helper должен отвечать на каждую входную строку по протоколу установленной версии Squid. Если включены параллельные каналы helper, сохраняйте идентификатор канала в ответе. Старый голый пример 301:URL не взаимозаменяем с текущим форматом result-and-key/value.
Выбирайте клиентское перенаправление, когда браузер должен знать новый URL. Ответ rewrite-url вместо этого просит Squid получить другой URL за исходным запросом клиента, что может оставить URL приложения и его состояние несогласованными.
Первоначальный HTTP-запрос уже дошёл до Squid до того, как helper сможет его перенаправить. Эта политика не может задним числом защитить тот запрос. TLS начинается на следующем HTTPS-соединении; один только туннель CONNECT не даёт шифрования.