Squid peut demander à un navigateur de réessayer une URL HTTP sélectionnée en HTTPS. La destination doit déjà servir la ressource correspondante en HTTPS ; exécuter Squid sur un Raspberry Pi ne crée pas cette capacité sur le site.

Pour l'interface url_rewrite_program de Squid 7, un helper peut renvoyer une redirection client comme celle-ci :

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

Il s'agit d'une réponse de helper illustrative pour une requête correspondante, pas d'un programme helper complet. Le navigateur reçoit la redirection et effectue une nouvelle requête vers l'URL HTTPS. Une URL hors de la politique de mise à niveau peut recevoir OK et rester inchangée.

Utilisez une liste connue de destinations compatibles HTTPS et analysez l'URL entrante. Conservez le chemin et la requête prévus, tenez compte des ports explicites et traitez les méthodes de requête avec discernement. Remplacer aveuglément chaque préfixe http suppose que chaque origine dispose d'un service HTTPS équivalent.

Le helper doit répondre à chaque ligne d'entrée selon le protocole de la version de Squid installée. Si des canaux de helper concurrents sont activés, conservez l'identifiant de canal dans la réponse. L'ancien exemple simple 301:URL n'est pas interchangeable avec le format actuel result-and-key/value.

Choisissez une redirection client lorsque le navigateur doit connaître la nouvelle URL. Une réponse rewrite-url demande plutôt à Squid de récupérer une autre URL derrière la requête d'origine du client, ce qui peut laisser les URL et l'état de l'application incohérents.

La requête HTTP initiale a déjà atteint Squid avant que le helper puisse la rediriger. Cette politique ne peut pas protéger rétroactivement cette requête. TLS commence sur la connexion HTTPS suivante ; un tunnel CONNECT seul n'apporte aucun chiffrement.

Articles similaires