Was eine Firmen-Firewall in einem VPN sehen kann und was nicht

Dasselbe Notebook erreicht das VPN von zu Hause und kann sich im Büro nicht verbinden, also muss jemand den Verkehr lesen. Blockieren und Lesen sind getrennte Befugnisse, und nur das zweite braucht einen Punkt auf dem Pfad plus ein Zertifikat, dem der Client vertraut. Eine Middlebox, die Ihren Handshake verwirft, hat nichts darüber gelernt, was Sie gesendet hätten. Zu entscheiden, womit von beidem Sie es zu tun haben, ist die ganze Aufgabe.

Blockieren und Lesen sind verschiedene Befugnisse

Eine Ablehnung ist billig und laut: der Socket öffnet sich und nichts antwortet, oder ein Reset kommt sofort. Nichts davon bedeutet Inspektion, denn keine Nutzlast hat die Leitung überquert.

Lesen braucht einen Endpunkt, der den Schutz beendet, sich mit einem Zertifikat ausweist und eine neue Verbindung weiter aufbaut. Dieser Endpunkt muss auf dem Pfad liegen und vom Client als vertrauenswürdig eingestuft sein. Eine Firewall, die nur Pakete weiterleitet, hat weder Position noch Berechtigung.

Was die Hülle kostenlos verrät

Jedes Tunnelpaket hat eine Außenseite, und die Außenseite muss routbar sein. Das heißt zwei Adressen, ein Protokoll, ein Port und eine Länge, dazu Zeitverhalten und Volumen. Jeder Router verarbeitet diese Felder ohnehin, und ein NAT schreibt Adresse und Port um, damit seine Zuordnungstabelle stimmt. Die Nutzlast bleibt versiegelt, sodass die Beobachtung bei der Tatsache endet, dass zwischen zwei Hosts ein Tunnel besteht.

Ein Hostname gehört nicht dazu. Websites lecken durch andere Türen, und die breiteste ist DNS: fragt das Notebook noch den lokalen Resolver, erscheinen die Namen im Klartext.

Zeitverhalten und Volumen verdienen Respekt, ohne überzeichnet zu werden. Bytes pro Minute können zeigen, dass eine große Übertragung um 14:20 beginnt; sie können nicht zeigen, welche Datei sich bewegt hat. Das ist eine echte Offenlegung über Verhalten und eine andere Kategorie als das Lesen von Inhalt.

TLS-Interzeption braucht eine Wurzel, der Sie schon vertrauen

Ein prüfendes Gerät bricht TLS nicht; es beendet es. Dem Client antwortet ein Zertifikat aus einer Wurzel, die die Organisation besitzt, und eine zweite Verbindung geht zum echten Ziel. Der Client akzeptiert das, weil diese Wurzel in seinem Trust Store liegt, weshalb ein verwaltetes Notebook keine Warnung zeigt. Kryptografie wurde nie besiegt; der Endpunkt wurde verschoben.

Deshalb hinterlässt die Anordnung auch Spuren. Der Aussteller auf der vorgelegten Kette gehört der Organisation und nicht einer öffentlichen CA, und ein Client kann das ohne Spezialwerkzeug sehen. Eine Kette, die in einer internen Wurzel endet, ist die Signatur der Interzeption, kein Defekt.

Warum ein VPN-Kanal keine HTTPS-Sitzung ist

Ein VPN-Datenkanal gibt einem Prüfer keinen solchen Halt. IKEv2 und WireGuard führen eigene Handshakes und Schlüsselpläne aus, ohne TLS zum Beenden, während OpenVPN sich TLS für seinen Steuerkanal in abgewandelter Form ausleiht, bevor es Daten auf seine eigene Weise schützt. Ein für HTTPS gebauter Proxy erkennt diese Sitzung nicht als etwas, das er parsen kann.

Ein Gerät, das eine Sitzung nicht parsen kann, kann sie trotzdem verwerfen. Deshalb sieht VPN-Blockierung meist wie ein Timeout aus und nicht wie eine Zertifikatswarnung, und deshalb ändert eine Ausnahme nichts.

Prüfung vom eigenen Rechner

Beginnen Sie mit der Kette, die die Seite vorlegt. Die Website-Details im Browser zeigen den Aussteller, und die Kommandozeile meldet dasselbe ohne die Zusammenfassung:

openssl s_client -connect example.com:443 -servername example.com

Trennen Sie dann einen abgelehnten Handshake mit Zählern vom gefilterten inneren Verkehr. Protokollieren Sie den Transportport vor jeder Drop-Regel und lesen Sie die Zähler nach dem Versuch:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Keine Logzeile am äußeren Socket bedeutet, dass der Handshake nie hinausging, der Pfad also den Tunnel ablehnt. Ein abgeschlossener Handshake, bei dem nur einige Ziele scheitern, bedeutet, dass der Tunnel funktioniert und die Richtlinie darin nicht. Keines der Ergebnisse erforderte das Lesen eines Bytes Nutzlast.

Das Lesen, das tatsächlich stattfindet, sitzt an den Rändern: Ein Split Tunnel übergibt internes HTTPS an einen Firmenproxy, und ein arbeitgebereigener Konzentrator legt am Ausgang alles offen. Was immer Sie finden, schalten Sie die Zertifikatsprüfung nicht ab, um eine Verbindung zu erzwingen, denn diese Prüfung ist das Einzige, was Inspektion von einem Angreifer trennt.