HTTP- vs. HTTPS-ProxysEs kommt darauf an, was der Proxy sehen kann

Die meisten Leitfäden zu "HTTP vs HTTPS Proxy" gehen stillschweigend davon aus, dass HTTPS das Upgrade ist: dasselbe Produkt, mehr Schloss. Wählen Sie HTTPS, so die Erzählung, und Ihr Datenverkehr ist verschlüsselt, Ihr Scraper ist sicherer, Ihr Konto schwerer zu fingerprinted. Diese Sichtweise ist falsch, und wer danach handelt, kauft das falsche Produkt aus dem falschen Grund.

Ein HTTP-Proxy und ein HTTPS-Proxy sind nicht zwei Qualitätsstufen eines Produkts. Sie beschreiben, wie viel von Ihrem Datenverkehr der Proxy lesen kann. Ein HTTP-Proxy sieht Ihre Anfragen im Klartext: Er kann sie inspizieren, cachen, Header umschreiben und nach URL routen. Bei einer HTTPS-Site öffnet derselbe Proxy einen undurchsichtigen Tunnel und leitet Bytes weiter, die er nicht entschlüsseln kann. Die Verschlüsselung, um die es Ihnen geht, stammt überhaupt nicht vom Proxy.

Die eigentliche Frage lautet also nicht "welcher Proxy ist sicherer". Sie lautet: Muss der Proxy Web-Datenverkehr inspizieren und darauf reagieren, oder nur verschlüsselten Datenverkehr blind weiterleiten? Sobald Sie es so formulieren, hört die Wahl auf, ein Label-Thema zu sein, und wird zu einer Frage der Sichtbarkeit. Der Rest dieses Artikels räumt mit dem Mythos auf und gibt Ihnen die eine entscheidende Frage.

HTTP vs HTTPS Proxies: die Kurzversion

Das ist die ganze Geschichte in drei Zeilen. HTTPS ist kein sichererer Proxy; es ist derselbe Proxy, der Ihren Datenverkehr nicht mehr sehen kann.

Der Mythos: HTTPS-Proxy ist einfach die sichere Version des HTTP-Proxys

Das Schloss in Ihrem Browser ist Ende-zu-Ende-Verschlüsselung zwischen Ihnen und der Website, ausgehandelt mit TLS (Transport Layer Security, dem Nachfolger von SSL). HTTPS ist nur HTTP, das innerhalb dieser TLS-Session übertragen wird. Entscheidend ist, dass diese Verschlüsselung eine Eigenschaft der Verbindung zwischen Ihrem Client und dem Ursprungsserver ist, kein Feature, das ein Proxy in der Mitte Ihnen gewährt.

Hier liegt der Punkt, den die "Upgrade"-Erzählung falsch versteht. Wenn Sie eine HTTPS-Seite über einen gewöhnlichen HTTP-Proxy abrufen, ist Ihr Datenverkehr immer noch Ende-zu-Ende verschlüsselt. Der Proxy entschlüsselt ihn nicht, schwächt ihn nicht ab und fügt nichts hinzu. Er leitet einfach die verschlüsselten Bytes weiter. Sie brauchen keinen speziellen "HTTPS-Proxy", um HTTPS sicher zu halten, weil die Sicherheit nie die Aufgabe des Proxys war.

Was die Leute als "HTTPS-Proxy" bezeichnen, bedeutet in der Regel eines von zwei nicht zusammenhängenden Dingen: ein Proxy, den Sie über eine verschlüsselte Verbindung erreichen (der Hop zwischen Ihnen und dem Proxy ist TLS-geschützt), oder ein abfangender Proxy, der TLS beendet, um Ihren Datenverkehr zu lesen und ihn dann erneut zum Ursprungsserver zu verschlüsseln. Das sind entgegengesetzte Ziele. Eines fügt Privatsphäre beim ersten Hop hinzu; das andere entfernt sie absichtlich, damit der Proxy sehen kann, was Sie senden. Beides unter "die sichere Version des HTTP-Proxys" zu subsumieren ist der Grund, warum der Mythos überlebt.

Die eigentliche Achse: Kann der Proxy Ihren Datenverkehr sehen?

Wenn man das Marketing weglässt, entscheidet eine Variable alles: ob der Proxy die Bytes, die er trägt, lesen kann. Ein Proxy ist eine Indirektionsschicht zwischen Ihnen und dem Ursprungsserver, und die einzige interessante Frage über diese Schicht ist, wie viel von Ihrer Kommunikation sie versteht.

Ein HTTP-Proxy versteht HTTP. Er liest die Anfragezeile und Header, sodass er eine Antwort cachen, einen Header entfernen oder einfügen, nach URL filtern, protokollieren, was Sie abgerufen haben, und Richtlinien durchsetzen kann. Diese Sichtbarkeit ist der eigentliche Zweck eines HTTP-Proxys: Er ist ein Spezialist, der im Web intelligent sein kann, weil er das Web lesen kann.

Bei einem HTTPS-Ziel verschwindet diese Sichtbarkeit von vornherein. Der Proxy kann nicht in eine TLS-Session hineinschauen, die er nicht beendet hat. Um HTTPS zu tragen, wechselt ein HTTP-Proxy daher die Rolle: Er hört auf, ein Leser zu sein, und wird zu einem blinden Relais. Der Mechanismus, der ihn umschaltet, ist die CONNECT-Methode, und ihr Verständnis löst die gesamte HTTP-versus-HTTPS-Verwirrung auf.

Wie CONNECT einen HTTP-Proxy in einen blinden Tunnel verwandelt

Das ist der Teil, den fast jede Erklärung überspringt, und es ist der, der das Thema verständlich macht. Ein Standard-HTTP-Proxy trägt Ihren HTTPS-Datenverkehr, ohne ihn jemals zu entschlüsseln, mithilfe einer speziellen Anfrage namens CONNECT. Die Abfolge ist kurz:

1. Ihr Client öffnet eine einfache Verbindung zum Proxy und sendet CONNECT example.com:443. Das ist der einzige Teil, den der Proxy liest: den Zielhost und den Port, nichts weiter.
2. Der Proxy öffnet eine TCP-Verbindung zu example.com auf Port 443 und antwortet bei Erfolg mit 200 Connection Established.
3. Von diesem Moment an hört der Proxy auf zu parsen. Er wird zu einer Pipe, die rohe Bytes in beide Richtungen weiterleitet, ohne sie zu interpretieren.
4. Ihr Client führt den TLS-Handshake direkt mit example.com durch, durch diese Pipe. Die verschlüsselte Session besteht zwischen Ihnen und dem Ursprungsserver.
5. Alle Ihre HTTP-Anfragen und die Antworten der Site fließen innerhalb dieses TLS-Tunnels. Der Proxy sieht nur Chiffretext, den er nicht lesen kann.

Das ist der ganze Trick. Ein gewöhnlicher HTTP-Proxy trägt bereits HTTPS, und er trägt es blind. Der Proxy weiß, dass Sie sich mit example.com:443 verbunden haben und wie viele Bytes übertragen wurden, kann aber nicht eine einzige Anfrage, einen Header oder ein Cookie innerhalb des Tunnels lesen. Das Ende-zu-Ende-TLS zwischen Ihnen und der Site ist genau das, was ihn draußen hält.

Zwei Konsequenzen folgen direkt daraus. Erstens kann der Proxy bei HTTPS nichts cachen oder umschreiben, weil Caching und Umschreiben das Lesen des Inhalts erfordern und er das nicht kann. Zweitens bleibt Ihr HTTPS-Datenverkehr vom Proxy genauso privat wie von jedem anderen auf dem Pfad. Der Proxy wird auf ein TCP-Relais reduziert, was dieselbe Aufgabe ist, die ein SOCKS5-Proxy für jedes Protokoll erledigt.

Was ist also ein "HTTPS-Proxy" wirklich?

Da ein HTTP-Proxy bereits HTTPS tunnelt, leistet der Begriff "HTTPS-Proxy" vage Arbeit. Pinnen Sie ihn auf eine von drei präzisen Bedeutungen fest:

1. Ein Proxy, den Sie über TLS erreichen

Hier liegt die Verschlüsselung beim ersten Hop: Die Verbindung von Ihrem Client zum Proxy ist selbst in TLS eingewickelt, sodass jemand, der Ihr lokales Netzwerk beobachtet, nur eine verschlüsselte Verbindung zum Proxy sieht. Der Proxy verwendet immer noch CONNECT, um HTTPS-Sites dahinter zu erreichen. Das ist auf feindseligen Netzwerken tatsächlich nützlich, weil es vor einem lokalen Beobachter verbirgt, zu welchen Sites Sie tunneln, aber es ist Privatsphäre auf dem Client-zu-Proxy-Bein, keine andere Proxy-Klasse.

2. Ein abfangender (TLS-beendender) Proxy

Das ist die entgegengesetzte Absicht. Der Proxy beendet Ihr TLS, entschlüsselt den Datenverkehr, liest oder modifiziert ihn und verschlüsselt ihn dann zum Ursprungsserver weiter. Um das zu tun, ohne dass der Client alarmiert wird, muss er ein Zertifikat präsentieren, dem der Client vertraut, weshalb Unternehmensnetzwerke auf verwalteten Geräten ein benutzerdefiniertes Root-Zertifikat installieren. Das ist genau die Man-in-the-Middle-Position, die TLS zu verhindern versucht. Es ist legitim für ein Unternehmen, das seinen eigenen ausgehenden Datenverkehr auf seinen eigenen Maschinen inspiziert, und überall sonst ein Warnsignal.

3. Umgangssprachlich für "ein Proxy, der HTTPS-Sites handhabt"

Meistens bedeutet "HTTPS-Proxy" einfach einen normalen HTTP-Proxy, der CONNECT unterstützt, was heute im Wesentlichen alle tun. Es gibt kein separates Produkt zu kaufen. Wenn ein Anbieter "HTTP-Proxys" und "HTTPS-Proxys" als zwei Stufen auflistet, fragen Sie, ob der Unterschied im Protokoll beim ersten Hop liegt oder reines Marketing ist. Meistens ist es Letzteres.

HTTP-Proxy vs HTTPS-Handling auf einen Blick

Lesen Sie die Tabelle als eine Aussage, nicht als zwölf Zellen: In dem Moment, in dem der Datenverkehr HTTPS ist, fällt jede "intelligente" Spalte auf "nein" zusammen, weil der Proxy nicht mehr sehen kann. Das ist keine Einschränkung eines schlechteren Produkts. Es ist die Verschlüsselung, die wie vorgesehen funktioniert.

Was das für Web Scraping bedeutet

Wenn Sie scrapen, ist fast jedes Ziel HTTPS, sodass fast jede Anfrage, die Sie über einen Proxy senden, ein CONNECT-Tunnel ist. Das hat eine klärende Implikation: Die Fähigkeit des Proxys, Ihren Datenverkehr zu lesen, ist für Sie irrelevant, weil er ihn ohnehin nicht lesen kann. Was tatsächlich zählt, ist der Teil, den der Proxy noch kontrolliert: die Exit-IP und wie die Anfrage den Ursprungsserver erreicht.

Deshalb ist die Obsession mit "HTTP versus HTTPS Proxy" eine Ablenkung beim Scraping. Das Protokoll auf dem Label sagt Ihnen nichts darüber, ob Sie blockiert werden. Was das entscheidet, ist die Reputation der IP, ihre Rotation und ob die Anfrage wie ein echter Browser aussieht, was die Frage Rechenzentrum versus privater Proxy ist, nicht die HTTP-versus-HTTPS-Frage. Ein Proxy, der Ihren verschlüsselten Datenverkehr nicht sehen kann, kann immer noch den Unterschied zwischen einem 200 und einem 403 ausmachen, rein durch die IP, von der er ausgeht.

Es hilft auch, Richtung von Sichtbarkeit zu trennen. Ob ein Proxy Ihren Datenverkehr liest, ist eine andere Achse als ob er vor Ihnen oder vor dem Ursprungsserver sitzt, was der Unterschied zwischen Forward- und Reverse-Proxy ist. Ein Scraping-Proxy ist ein Forward-Proxy, und das obige CONNECT-Verhalten gilt für ihn genauso, unabhängig vom Protokoll-Label auf der gekauften Stufe.

Es gibt einen echten Sicherheitsvorbehalt. Da ein abfangender Proxy im CONNECT-Pfad sitzen und sein eigenes Zertifikat präsentieren kann, routen Sie niemals Scraping oder sensiblen Datenverkehr über einen kostenlosen oder unbekannten "HTTPS-Proxy", der Sie auffordert, einer benutzerdefinierten Zertifizierungsstelle zu vertrauen. Ende-zu-Ende-TLS schützt Sie nur, wenn niemand in der Mitte es beendet hat. Ein vertrauenswürdiger Anbieter tunnelt Ihr HTTPS mit CONNECT und bittet Sie nie, ein Root-Zertifikat zu installieren.

CONNECT in der Praxis beobachten

Der sauberste Weg, all das zu verinnerlichen, ist, eine Anfrage beide Wege zu beobachten. Richten Sie einen Kommandozeilen-Client auf einen HTTP-Proxy und fordern Sie eine HTTPS-Seite an: Der Client gibt CONNECT aus, der Proxy leitet den Tunnel weiter, und Ihr TLS-Handshake erfolgt mit dem Ursprungsserver, nicht dem Proxy.

# Plain HTTP: the proxy reads the full request
# and could cache, log, or rewrite it.
curl -x "http://user:[email protected]:8080" \
     "http://example.com/page"

# HTTPS: same proxy, but -v shows it send
# CONNECT first, then a blind TLS tunnel.
curl -v -x "http://user:[email protected]:8080" \
     "https://example.com/page"

In der ausführlichen Ausgabe des zweiten Befehls sehen Sie eine Zeile wie CONNECT example.com:443, gefolgt von 200 Connection Established, und erst dann den TLS-Handshake. Dieser Handshake geht zum Ursprungsserver und nicht zum Proxy, was der visuelle Beweis ist, dass Ihr HTTPS Ende-zu-Ende ist. Der Proxy hat Ihre Bytes verschoben, ohne sie jemals zu lesen.

Wenn Sie möchten, dass der Proxy seine ausgehende IP steuert, anstatt nur weiterzuleiten, gilt dieselbe CONNECT-Mechanik, außer dass ein verwalteter Endpunkt die Rotation und Wiederholungen für Sie übernimmt. Das ist der Unterschied zwischen einem einzelnen statischen Hop und einem gepoolten Endpunkt, derselbe Gedanke hinter einem API-Proxy, der viele Ausgänge unter einer Adresse bündelt.

Häufig gestellte Fragen

Ist ein HTTPS-Proxy sicherer als ein HTTP-Proxy?

Nicht von Natur aus. Die Verschlüsselung, die eine HTTPS-Site schützt, ist Ende-zu-Ende-TLS zwischen Ihnen und dem Ursprungsserver, und ein gewöhnlicher HTTP-Proxy bewahrt sie, indem er den Datenverkehr mit CONNECT tunnelt. "HTTPS-Proxy" bedeutet in der Regel entweder, dass der Hop zum Proxy verschlüsselt ist oder dass der Proxy Ihr TLS abfängt, was das Gegenteil von mehr Sicherheit ist.

Kann ein HTTP-Proxy HTTPS-Datenverkehr verarbeiten?

Ja, und fast alle tun es. Wenn Sie eine HTTPS-URL anfordern, sendet Ihr Client dem Proxy einen CONNECT-Befehl mit dem Zielhost und dem Port. Der Proxy öffnet eine TCP-Verbindung und leitet dann die verschlüsselten Bytes blind weiter. Er entschlüsselt den Datenverkehr nicht; Ihre TLS-Session besteht mit der Website, nicht dem Proxy.

Was ist die CONNECT-Methode?

CONNECT ist eine HTTP-Anfrage, die einen Proxy auffordert, einen rohen TCP-Tunnel zu einem Ziel zu öffnen, anstatt eine Ressource abzurufen. Der Client sendet CONNECT host:port, der Proxy stellt die Verbindung her und antwortet mit 200, und von da an leitet er Bytes weiter, ohne sie zu parsen. So tragen HTTP-Proxys HTTPS, SSH und andere getunnelte Protokolle.

Entschlüsselt ein Proxy meinen HTTPS-Datenverkehr?

Ein normaler Proxy tut das nicht. Mit CONNECT sieht er nur den Zielhost und den verschlüsselten Byte-Strom. Die Ausnahme ist ein abfangender Proxy, der TLS beendet und sein eigenes Zertifikat präsentiert, der Ihren Datenverkehr lesen kann, aber erfordert, dass Ihr Gerät seiner Zertifizierungsstelle vertraut. Wenn ein Proxy Sie auffordert, ein Root-Zertifikat zu installieren, kann er alles lesen, was Sie senden.

Welchen Proxy sollte ich für Web Scraping verwenden?

Beim Scraping spielt das Label HTTP versus HTTPS kaum eine Rolle, weil fast alle Ziele HTTPS sind und unabhängig davon durch CONNECT getunnelt werden. Was zählt, ist die Reputation und Rotation der Exit-IP. Wählen Sie auf Basis des Rechenzentrum-versus-privater-Proxy-Kompromisses und ob der Proxy rotiert und wiederholt, nicht des Protokollnamens.

Was ist der Unterschied zwischen einem HTTP-Proxy und einem SOCKS5-Proxy?

Ein HTTP-Proxy versteht Web-Datenverkehr und kann Klartext-HTTP cachen, umschreiben und filtern, während er HTTPS blind mit CONNECT tunnelt. Ein SOCKS5-Proxy versteht nichts über das Protokoll, das er trägt; er leitet rohen TCP oder UDP für jede Anwendung weiter. Bei HTTPS insbesondere enden beide damit, einen undurchsichtigen verschlüsselten Stream weiterzuleiten.

BA

Bilal Ahmed

Softwareentwickler · Crawlbase

Softwareentwickler, der einige der meistgelesenen Beiträge im Crawlbase-Blog verfasst hat, über Web Scraping, Proxys und Daten-Tooling.