Das Etikett HTTPS-Proxy beschreibt nur den Transport zwischen Ihrem Client und dem Proxy und nichts weiter. Es besagt nicht, dass die dahinterliegende Website durch dieselbe Verbindung verschlüsselt wird, und es besagt nicht, dass der Proxy die Seite lesen kann. Sobald Sie die beiden Verbindungen trennen, verlieren Zertifikatfehler ihr Rätsel und der Vergleich mit einem VPN wird konkret.

Zwei Endpunktpaare, zwei Prüfungen

Im gewöhnlichen Tunnelmodus gibt es zwei TLS-Beziehungen. Die erste läuft von Ihrem Client zum Proxy und authentifiziert den Proxy. Die zweite läuft von Ihrem Client zur Website innerhalb des Tunnels und authentifiziert die Website. Sie scheitern unabhängig und werden unabhängig konfiguriert.

Sie haben getrennte Vertrauensentscheidungen, getrennte Zertifikatsketten und getrennte Fehlermeldungen. Ein Proxy mit einer organisatorischen CA und eine öffentliche Website mit einer öffentlichen Kette können legitim unterschiedliche Prüfkonfigurationen benötigen, und das ist keine Fehlkonfiguration.

Behandeln Sie sie als zwei Verbindungen, die zufällig einen Socket teilen, denn genau das sind sie.

Was CONNECT tatsächlich tunnelt

Der Client sendet eine CONNECT-Anfrage mit Host und Port, und der Proxy öffnet eine TCP-Verbindung zu diesem Ziel. Nach der Antwort des Proxys werden die folgenden Bytes ohne Interpretation weitergeleitet, weshalb der TLS-Handshake der Website unverändert durch den Proxy läuft. Der Proxy erfährt damit den Zielnamen und die Verbindungsmetadaten und erhält aus dieser Anordnung keine entschlüsselten Seiten.

Diese Unterscheidung ist das gesamte Sicherheitsargument für den Tunnelmodus, und sie ist zugleich seine Grenze.

Ein HTTP-Proxy ohne TLS auf dem Proxy-Hop transportiert eine HTTPS-Website weiterhin über CONNECT. Der Austausch zwischen Client und Proxy erfolgt im Klartext, die Website-Verbindung dagegen nicht, und das Ganze als HTTPS-Proxy zu bezeichnen verbirgt diesen Unterschied.

Welches Zertifikat fehlgeschlagen ist

Wenn die Prüfung fehlschlägt, lesen Sie den in der Fehlermeldung genannten Endpunkt, bevor Sie eine Vertrauenseinstellung ändern. Die beiden Fehler sehen im Terminal ähnlich aus und deuten auf völlig unterschiedliche Korrekturen hin, weshalb die erste Frage immer lautet, welche Verbindung abgelehnt wurde.

curl trennt die Optionen genau aus diesem Grund. Die CA-Datei des Proxys konfiguriert die Prüfung des Proxys, während die CA-Datei die Prüfung des Servers konfiguriert, und das Verhalten des zutreffenden Vertrauensspeichers hängt auch davon ab, wie curl gebaut wurde.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Eine Prüfung zu unterdrücken ist keine Reparatur. Sie belegt nichts über einen der beiden Endpunkte.

Inspektion ist eine andere Anordnung

TLS-Inspektion ist kein Tunneling. Ein inspizierender Vermittler beendet die websitegerichtete Vertrauensbeziehung und präsentiert dem Client sein eigenes Zertifikat, sodass der Client den Vermittler statt der Website verifiziert. Das kann unter einem genehmigten Design legitim sein, und es ist eine wesentlich andere Aussage als byteweises Weiterleiten. Gehen Sie nicht davon aus, dass jeder Proxy inspiziert, und gehen Sie nicht davon aus, dass ein verschlüsselter Proxy-Hop das ausschließt.

Eine organisatorische CA in Ihrem Vertrauensspeicher ist ein Hinweis darauf, in welcher Anordnung Sie sich befinden, kein Beweis. Fragen Sie nach dem Design, statt es aus einer Zertifikatskette abzuleiten.

Diese beiden Anordnungen geben unterschiedliche Antworten auf die Frage, wer die Seite lesen kann.

Vergleichen Sie Proxy und VPN an denselben vier Zeilen

Der Vergleich wird erst nützlich, wenn beide Bereitstellungen gleich beschrieben werden.

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

Ein Proxy, der für eine Anfrage konfiguriert ist, deckt diese Anfrage ab. Er leitet nicht jeden Prozess des Geräts durch sich hindurch, und das Beispielkommando ist genau so eng. Die Abdeckung eines VPN hängt von seinem Routing und seiner Anwendungsrichtlinie ab, die ebenfalls geprüft und nicht angenommen werden muss. Keine der beiden Optionen deckt alles ab, nur weil sie installiert wurde.

Schreiben Sie die vier Zeilen für jede Option, und das Argument löst sich meist von selbst. Der nützliche Vergleich ist nicht, welches Etikett verschlüsselter klingt. Sondern welche Segmente geschützt sind, wer an ihren Enden verifiziert wird, welchen Vermittlern Sie vertrauen und welchen Verkehr die Richtlinie tatsächlich umfasst.

Ähnliche Artikel