HTTP- und HTTPS-Proxies

Ein HTTP-Proxy nimmt Webanfragen Ihres Browsers oder Ihrer Anwendung an und verbindet sich für Sie mit dem Ziel. Er kann gewöhnlichen HTTP-Datenverkehr und bei Unterstützung der Methode CONNECT auch verschlüsselten HTTPS-Datenverkehr transportieren. Ein HTTPS-Proxy verschlüsselt zusätzlich die Verbindung zwischen Ihrer Anwendung und dem Proxy selbst.

Das sind zwei getrennte Entscheidungen: wie Ihre Anwendung den Proxy erreicht und wie sie darüber mit der Website kommuniziert. Wer beides unterscheidet, kann die passenden Verbindungseinstellungen wählen. Den Vergleich der Proxyprotokolle behandelt SOCKS- und HTTP-Proxies.

Wie ein HTTP-Proxy eine Webanfrage behandelt

Angenommen, ein Überwachungsskript fordert http://example.com/catalog an. Statt sich direkt mit der Website zu verbinden, kontaktiert es den eingerichteten Proxy. Bei HTTP/1.1 sendet es die vollständige Ziel-URL, damit der Proxy Server und Seite kennt. Der Proxy leitet die Anfrage weiter und gibt die Websiteantwort an das Skript zurück.

In diesem Modus verarbeitet der Proxy HTTP-Nachrichten. Er kann die Methode wie GET oder POST, die angeforderte Adresse, Header und übermittelte Daten lesen. Entsprechend eingerichtete Software kann Zugangsregeln anwenden, Anfragen protokollieren oder geeignete Antworten zwischenspeichern. Caching ist optional und richtet sich nach den Cache-Regeln der Antwort. HTTP-Proxyzugang bedeutet nicht, dass jede Seite zwischengespeichert wird.

Die Website erhält die Netzwerkverbindung von der Ausgangs-IP-Adresse des Proxys. HTTP sagt nichts über deren Herkunft oder Zuweisungsdauer aus. Dasselbe Verbindungsprotokoll kann mit Rechenzentrums-, ISP-, Residential- oder Mobilfunkadressen, festen IP-Adressen oder einem rotierenden Pool angeboten werden.

Wie ein HTTP-Proxy eine HTTPS-Website öffnet

Eine HTTPS-Website verwendet TLS zum Schutz des Austauschs zwischen Anwendung und Website. Für diesen Austausch erstellt ein HTTP-Proxy zuerst einen Tunnel. Eine Anfrage an https://example.com/catalog läuft wie folgt ab:

1. Die Anwendung verbindet sich mit dem Proxy und fordert mit CONNECT einen Tunnel zu example.com:443 an. Die Anfrage nennt Zielhost und Port ohne den Seitenpfad.
2. Der Proxy prüft Zugang und Zielberechtigung einschließlich erforderlicher Proxyauthentifizierung. Er öffnet eine Verbindung zum Ziel und bestätigt den fertigen Tunnel.
3. Die Anwendung führt durch den Tunnel einen TLS-Handshake mit der Website aus und prüft deren Zertifikat.
4. Die Anwendung sendet ihre Webanfrage innerhalb dieser TLS-Verbindung. Der Proxy leitet die verschlüsselten Bytes in beide Richtungen weiter.

Der Proxy muss die Seite nicht lesen, um sie zu übertragen. Anwendung und Website bleiben die Endpunkte der Website-TLS-Verbindung. CONNECT liefert den Tunnel; TLS liefert Verschlüsselung und Schutz vor unbemerkten Veränderungen.

Deshalb kann ein HTTP-Proxy eine HTTPS-Website öffnen, auch wenn seine Adresse mit http:// beginnt. Der HTTPS-Schutz der Website arbeitet innerhalb des Tunnels. Er benötigt keine TLS-Verbindung zwischen Anwendung und Proxy.

Was ein HTTPS-Proxy ergänzt

Bei einem HTTPS-Proxy baut die Anwendung zuerst TLS zum Proxy auf und prüft dessen Zertifikat. Darin sendet sie ihre HTTP-Anfragen oder die CONNECT-Anfrage für einen Tunnel. Ein Netzwerkbeobachter zwischen Anwendung und Proxy kann diese Anfragen nicht lesen.

Für ein HTTPS-Ziel verwaltet die Anwendung zwei getrennte TLS-Verbindungen: eine zum Proxy und eine durch den Tunnel zur Website. Der Proxy entfernt den an ihn gerichteten äußeren Schutz; die Websitedaten darin bleiben verschlüsselt. Er leitet diese Bytes an die Website weiter, die sie entschlüsseln kann. Bei einem HTTP-Ziel gibt es kein inneres TLS: Nur die Verbindung zum Proxy ist geschützt.

Dieser Vergleich beschreibt gewöhnliche Proxyweiterleitung mit aktivierter Zertifikatsprüfung, ohne HTTPS-Inspektion oder separates VPN. Die Verschlüsselung zum Proxy macht aus einer HTTP-Website keine HTTPS-Website.

Was Proxy und Website sehen können

Bei einem HTTPS-Ziel kann ein weiterleitender Proxy weder Seitenpfad, Abfrageparameter, Cookies und Formulardaten noch zurückgelieferte Inhalte innerhalb der TLS-Verbindung lesen. Er kennt weiterhin die verbundene Client-IP-Adresse, den in CONNECT angeforderten Zielhost und Port sowie Zeitpunkt und Datenvolumen. TLS zum Proxy verbirgt CONNECT vor Beobachtern dieses Netzabschnitts, nicht vor dem Proxy, der die Anfrage ausführen muss.

Proxyzugangsdaten werden getrennt von einer Websiteanmeldung gesendet. Basic-Proxyauthentifizierung codiert Benutzername und Passwort mit Base64, das sich ohne geheimen Schlüssel zurückwandeln lässt. Über eine einfache HTTP-Proxyverbindung schützt das nicht vor Netzwerkbeobachtern. HTTPS zur Website beginnt innerhalb des Tunnels und deckt die frühere Proxyanmeldung nicht ab. TLS zum Proxy schützt diese während der Übertragung.

Am anderen Ende erhält die Website Datenverkehr von der Ausgangs-IP-Adresse und liest die an sie gerichteten Anfragen. Sie kann ein Konto, Sitzungscookie oder andere Anwendungsinformationen erkennen. Die Wahl eines HTTPS-Proxys entfernt diese Kennungen nicht und verbessert nicht automatisch die Akzeptanz der Ausgangs-IP-Adresse.

HTTPS-Inspektion ist eine andere Einrichtung, die manche verwalteten Netzwerke und Debugging-Werkzeuge verwenden. Die Anwendung vertraut einer Zertifizierungsstelle des prüfenden Proxys. Dieser kann dann Datenverkehr lesen und auf beiden Seiten getrennte TLS-Verbindungen unterhalten. Gewöhnliche CONNECT-Weiterleitung verlangt kein solches Zertifikat. Vertrauen in das eigene Serverzertifikat des HTTPS-Proxys ist von der Berechtigung zur Nachbildung von Websites getrennt.

Verbindungseinstellungen richtig lesen

Eine Proxyeinstellung benötigt Adresse, Port, Verbindungsprotokoll und erforderliche Authentifizierung. Das Protokoll der Proxy-URL gilt für den Proxy. Das Protokoll der Ziel-URL gilt für die Website.

Diese curl-Befehle rufen dieselbe HTTPS-Website über zwei unterschiedliche Proxyverbindungen ab. Ersetzen Sie Proxyhostname und Port durch die Werte des gewählten Verbindungsverfahrens:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

Der erste Befehl verbindet sich per HTTP mit dem Proxy und erstellt anschließend CONNECT und TLS zur Website. Der zweite erstellt zuerst TLS zum HTTPS-Proxy und transportiert darin die separate TLS-Verbindung zur Website. Ergänzen Sie in beiden Fällen die vom Proxydienst erforderliche Authentifizierung.

Ein einfacher Austausch von http:// durch https:// macht einen reinen HTTP-Port nicht zum TLS-Endpunkt. Liefert der Dienst einen Hostnamen für HTTPS-Zugang, verwenden Sie diesen. Sein Ersatz durch eine IP-Adresse kann eine Abweichung vom Zertifikatsnamen verursachen.

Anwendungsbezeichnungen müssen ebenso sorgfältig gelesen werden. Ein Feld „HTTPS-Proxy“ kann den Proxy für HTTPS-Websites auswählen, obwohl es ihn per unverschlüsseltem HTTP erreicht. Auch die curl-Variable HTTPS_PROXY wählt einen Proxy für HTTPS-Ziele; ihr Wert darf korrekt mit http:// beginnen. Die Bezeichnung sagt, welche Anfragen die Einstellung nutzen. Das Proxyschema bestimmt den Verbindungsaufbau.

DNS und der vom Proxy erfasste Datenverkehr

Übermittelt ein HTTP-Client einen Zielhostnamen, löst der Proxy gewöhnlich dessen IP-Adresse auf und verbindet sich damit. Der Client führt eine getrennte Abfrage aus, wenn er den Proxyhostnamen zur Erreichbarkeit auflösen muss. Ein Browser kann außerdem DNS-Anfragen für Vorhersagen oder andere Funktionen senden. Das sind getrennte Auflösungen; ein Webproxy leitet nicht jede DNS-Anfrage über sich.

Die Einstellung gilt für tatsächlich an den Proxy gesendeten Anwendungsverkehr. Ein anderes Programm kann weiter direkt verbinden; eine Ausnahmeliste kann den Proxy für bestimmte Websites umgehen. Beispielsweise verändert ein proxynutzendes API-Skript nicht den Weg eines unabhängigen Browsers. Prüfen Sie die Ausgangsadresse aus der später verwendeten Anwendung und Konfiguration.

HTTP/2 zur Website und HTTP/2 zum Proxy

HTTP/2 ermöglicht mehreren Dialogen, eine Verbindung über getrennte Streams zu teilen. Bei einem Proxy zählt, welche Verbindung es unterstützt. Eine Anwendung kann HTTP/2 mit einer Website innerhalb eines per HTTP/1.1-CONNECT erstellten Tunnels aushandeln. Der Proxy leitet verschlüsselte Bytes weiter und muss die HTTP/2-Nachrichten der Website nicht verstehen.

HTTP/2 zwischen Anwendung und Proxy ist eine getrennte Fähigkeit. Jeder CONNECT-Tunnel verwendet einen eigenen HTTP/2-Stream. Mehrere Tunnel können deshalb dieselbe Proxyverbindung teilen. Beispielsweise nutzen Tunnel zu zwei Websites diese Verbindung, behalten aber getrennte Zielverbindungen und Website-TLS-Sitzungen. Das reduziert zusätzliche Client-Proxy-Verbindungen, ohne dem Proxy Zugriff auf verschlüsselte Websiteanfragen zu geben.

Beide Seiten müssen den gewählten Modus unterstützen. HTTPS allein legt HTTP/2 nicht fest: Ein HTTPS-Proxy kann HTTP/1.1 verwenden. Die Leistung hängt außerdem von Client, Übertragungsweg, Serverlast und Verbindungswiederverwendung ab. HTTP/2 verspricht keinen Geschwindigkeitsgewinn für jede Aufgabe.

Ein gewöhnlicher CONNECT-Tunnel kann auch andere TCP-Protokolle tragen, wenn Anwendung und Proxy das erlauben; Zielports können beschränkt sein. Er leitet kein UDP weiter. HTTP/3 verwendet QUIC über UDP und läuft daher nicht auf dieselbe Weise durch diesen TCP-Tunnel. HTTP-basierte UDP-Weiterleitung verwendet Zusatzmechanismen wie CONNECT-UDP und benötigt kompatible Implementierungen. HTTPS- oder HTTP/2-Unterstützung allein belegt dies nicht.

Wo HTTP- und HTTPS-Proxyzugang nützlich ist

Für Browsen und Websitetests bietet ein HTTP-Proxy mit CONNECT ein Verfahren für HTTP- und HTTPS-Ziele. Ein Team kann eine Website aus dem Proxynetzwerk betrachten, während der Browser weiterhin Darstellung, Cookies und Websiteanmeldungen verwaltet.

Crawler, API-Clients und geplante Überwachungen können Anfragen per HTTP-Client über eine ausgewählte Ausgangs-IP-Adresse senden und die Ziel-URLs beibehalten. Die Anwendung erstellt weiterhin Anfragen und verarbeitet Antworten. In einem HTTPS-Tunnel transportiert der Proxy den Austausch, ohne jede Seite oder jeden API-Aufruf auszuwerten.

Ein TLS-geschützter HTTPS-Proxy hilft, wenn auch die Verbindung zum Proxy einschließlich Anmeldung und Zielanfragen geschützt werden muss. Das ist bei Wegen über nicht selbst kontrollierte Netzwerke wichtig. Der Client muss TLS zum Proxy selbst unterstützen. HTTPS-Websites öffnen zu können, reicht nicht.

Verbindungsfehler einordnen

Ein Fehler kann beim Erreichen des Proxys, beim Tunnelaufbau oder bei der Websitekommunikation auftreten. Die Stufe sagt mehr aus als der Fehlercode allein.

Ein fertiger Tunnel und TLS-Handshake zeigen einen funktionierenden Verbindungsweg. Sie garantieren nicht die Annahme eines bestimmten Kontos, einer Ausgangs-IP-Adresse oder Anfrage durch die Website. Anmeldeprüfung, CAPTCHA oder Anfragelimit können deshalb trotz funktionierendem Proxy Maßnahmen auf Website- oder Anwendungsebene verlangen.