Ausgewählte HTTP-Anfragen von Squid auf HTTPS umleiten

Squid kann einen Browser bitten, eine ausgewählte HTTP-URL über HTTPS erneut zu versuchen. Das Ziel muss die entsprechende Ressource bereits über HTTPS bereitstellen; Squid auf einem Raspberry Pi laufen zu lassen, erzeugt diese Fähigkeit nicht auf der Website.

Für die url_rewrite_program-Schnittstelle von Squid 7 kann ein Helper eine Client-Weiterleitung wie diese zurückgeben:

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

Dies ist eine beispielhafte Helper-Antwort für eine passende Anfrage, kein vollständiges Helper-Programm. Der Browser erhält die Weiterleitung und stellt eine neue Anfrage an die HTTPS-URL. Eine URL außerhalb der Upgrade-Richtlinie kann OK erhalten und unverändert bleiben.

Verwenden Sie eine bekannte Liste HTTPS-fähiger Ziele und analysieren Sie die eingehende URL. Bewahren Sie den beabsichtigten Pfad und die Query, berücksichtigen Sie explizite Ports und behandeln Sie Anforderungsmethoden bewusst. Blindes Ersetzen jedes http-Präfixes setzt voraus, dass jeder Origin einen gleichwertigen HTTPS-Dienst hat.

Der Helper muss jede Eingabezeile nach dem Protokoll der installierten Squid-Version beantworten. Sind parallele Helper-Kanäle aktiviert, muss die Kanal-ID in der Antwort erhalten bleiben. Das alte bloße 301:URL-Beispiel ist nicht mit dem aktuellen result-and-key/value-Format austauschbar.

Wählen Sie eine Client-Weiterleitung, wenn der Browser die neue URL kennen soll. Eine rewrite-url-Antwort verlangt stattdessen, dass Squid eine andere URL hinter der ursprünglichen Client-Anfrage abruft, was Anwendungs-URLs und -Zustand inkonsistent lassen kann.

Die ursprüngliche HTTP-Anfrage ist bereits zu Squid gelangt, bevor der Helper sie umleiten kann. Diese Richtlinie kann diese Anfrage nicht rückwirkend schützen. TLS beginnt erst mit der folgenden HTTPS-Verbindung; ein CONNECT-Tunnel allein bietet keine Verschlüsselung.