Omdiriger utvalgte HTTP-forespørsler fra Squid til HTTPS
Returner en klientomdirigering for kjente HTTPS-kompatible nettsteder i stedet for å stille endre hver HTTP-opprinnelses-URL eller anta at proxyen kan opprette TLS-støtte ved opprinnelsen.
Squid kan be en nettleser om å prøve en utvalgt HTTP-URL på nytt over HTTPS. Målet må allerede levere den tilhørende ressursen over HTTPS; å kjøre Squid på en Raspberry Pi skaper ikke denne egenskapen på nettstedet.
For Squid 7s url_rewrite_program-grensesnitt kan en helper returnere en klientomdirigering som denne:
OK status=307 url="https://www.example.com/help"
Dette er ett illustrerende helpersvar for en samsvarende forespørsel, ikke et fullstendig helperprogram. Nettleseren mottar omdirigeringen og sender en ny forespørsel til HTTPS-URL-en. En URL utenfor oppgraderingspolicyen kan få OK og forbli uendret.
Bruk en kjent liste over HTTPS-kompatible mål og analyser den innkommende URL-en. Bevar den tiltenkte banen og queryen, ta hensyn til eksplisitte porter og håndter forespørselsmetoder bevisst. Blind erstatning av hvert http-prefiks forutsetter at hver opprinnelse har en tilsvarende HTTPS-tjeneste.
Helperen må svare på hver inndatalinje etter protokollen til den installerte Squid-versjonen. Hvis samtidige helperkanaler er aktivert, må kanalidentifikatoren bevares i svaret. Det gamle bare 301:URL-eksempelet kan ikke byttes ut med dagens result-and-key/value-format.
Velg en klientomdirigering når nettleseren bør kjenne den nye URL-en. Et rewrite-url-svar ber i stedet Squid hente en annen URL bak klientens opprinnelige forespørsel, noe som kan etterlate applikasjonens URL-er og tilstand inkonsistente.
Den første HTTP-forespørselen har allerede reist til Squid før helperen kan omdirigere den. Denne policyen kan ikke beskytte den forespørselen i ettertid. TLS starter på den neste HTTPS-tilkoblingen; en CONNECT-tunnel alene gir ingen kryptering.