Geselecteerde HTTP-verzoeken van Squid naar HTTPS omleiden
Retourneer een clientomleiding voor bekende HTTPS-geschikte sites in plaats van stil elke HTTP-oorsprong-URL te wijzigen of aan te nemen dat de proxy TLS-ondersteuning bij de oorsprong kan maken.
Squid kan een browser vragen een geselecteerde HTTP-URL opnieuw te proberen via HTTPS. De bestemming moet de bijbehorende bron al via HTTPS leveren; Squid op een Raspberry Pi draaien maakt die mogelijkheid niet op de website.
Voor de url_rewrite_program-interface van Squid 7 kan een helper een clientomleiding zoals deze retourneren:
OK status=307 url="https://www.example.com/help"Dit is één illustratief helperantwoord voor een overeenkomend verzoek, geen compleet helperprogramma. De browser ontvangt de omleiding en doet een nieuw verzoek naar de HTTPS-URL. Een URL buiten het upgradbeleid kan OK krijgen en ongewijzigd blijven.
Gebruik een bekende lijst met HTTPS-geschikte bestemmingen en analyseer de inkomende URL. Behoud het bedoelde pad en de query, houd rekening met expliciete poorten en behandel verzoekmethoden bewust. Elk http-voorvoegsel blind vervangen veronderstelt dat elke oorsprong een gelijkwaardige HTTPS-dienst heeft.
De helper moet elke invoerregel beantwoorden volgens het protocol van de geïnstalleerde Squid-versie. Als gelijktijdige helperkanalen zijn ingeschakeld, behoud dan de kanaalidentificatie in het antwoord. Het oude kale 301:URL-voorbeeld is niet uitwisselbaar met het huidige result-and-key/value-formaat.
Kies een clientomleiding wanneer de browser de nieuwe URL moet kennen. Een rewrite-url-antwoord vraagt Squid juist om een andere URL achter het oorspronkelijke verzoek van de client op te halen, wat de URL's en status van de applicatie inconsistent kan achterlaten.
Het eerste HTTP-verzoek is al naar Squid gereisd voordat de helper het kan omleiden. Dit beleid kan dat verzoek niet met terugwerkende kracht beschermen. TLS begint op de volgende HTTPS-verbinding; een CONNECT-tunnel alleen biedt geen versleuteling.