Redirigir solicitudes HTTP seleccionadas de Squid a HTTPS

Squid puede pedir a un navegador que reintente una URL HTTP seleccionada sobre HTTPS. El destino ya debe servir el recurso correspondiente sobre HTTPS; ejecutar Squid en una Raspberry Pi no crea esa capacidad en el sitio web.

Para la interfaz url_rewrite_program de Squid 7, un helper puede devolver una redirección de cliente como esta:

OK status=307 url="https://www.example.com/help"

Esta es una respuesta ilustrativa de helper para una solicitud coincidente, no un programa helper completo. El navegador recibe la redirección y realiza una nueva solicitud a la URL HTTPS. Una URL fuera de la política de actualización puede recibir OK y quedar sin cambios.

Use una lista conocida de destinos compatibles con HTTPS y analice la URL entrante. Conserve la ruta y la query previstas, tenga en cuenta los puertos explícitos y trate los métodos de solicitud con deliberación. Reemplazar a ciegas cada prefijo http supone que cada origen tiene un servicio HTTPS equivalente.

El helper debe responder a cada línea de entrada según el protocolo de la versión de Squid instalada. Si los canales de helper concurrentes están habilitados, conserve el identificador de canal en la respuesta. El antiguo ejemplo simple 301:URL no es intercambiable con el formato actual de result-and-key/value.

Elija una redirección de cliente cuando el navegador deba conocer la nueva URL. Una respuesta rewrite-url, en cambio, pide a Squid obtener otra URL detrás de la solicitud original del cliente, lo que puede dejar inconsistentes las URL de la aplicación y su estado.

La solicitud HTTP inicial ya viajó hasta Squid antes de que el helper pueda redirigirla. Esta política no puede proteger retroactivamente esa solicitud. TLS comienza en la conexión HTTPS posterior; un túnel CONNECT por sí solo no proporciona cifrado.