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.

Relaterte artikler