Redirecionar solicitações HTTP selecionadas do Squid para HTTPS
Retorne um redirecionamento de cliente para sites conhecidos compatíveis com HTTPS em vez de alterar silenciosamente cada URL de origem HTTP ou presumir que o proxy pode criar suporte TLS na origem.
O Squid pode pedir a um navegador que repita uma URL HTTP selecionada por HTTPS. O destino já deve servir o recurso correspondente por HTTPS; executar o Squid em um Raspberry Pi não cria essa capacidade no site.
Para a interface url_rewrite_program do Squid 7, um helper pode retornar um redirecionamento de cliente como este:
OK status=307 url="https://www.example.com/help"Esta é uma resposta ilustrativa de helper para uma solicitação correspondente, não um programa helper completo. O navegador recebe o redirecionamento e faz uma nova solicitação à URL HTTPS. Uma URL fora da política de atualização pode receber OK e permanecer inalterada.
Use uma lista conhecida de destinos compatíveis com HTTPS e analise a URL de entrada. Preserve o caminho e a query pretendidos, considere portas explícitas e trate os métodos de solicitação com deliberação. Substituir cegamente cada prefixo http pressupõe que cada origem tenha um serviço HTTPS equivalente.
O helper deve responder a cada linha de entrada de acordo com o protocolo da versão do Squid instalada. Se os canais helper simultâneos estiverem habilitados, preserve o identificador do canal na resposta. O antigo exemplo simples 301:URL não é intercambiável com o formato atual result-and-key/value.
Escolha um redirecionamento de cliente quando o navegador deve conhecer a nova URL. Uma resposta rewrite-url, em vez disso, pede ao Squid para buscar outra URL atrás da solicitação original do cliente, o que pode deixar as URLs do aplicativo e o estado inconsistentes.
A solicitação HTTP inicial já viajou até o Squid antes que o helper possa redirecioná-la. Esta política não pode proteger retroativamente essa solicitação. O TLS começa na conexão HTTPS seguinte; um túnel CONNECT sozinho não fornece criptografia.