VPN und Tor ersetzen kein HTTPS: wo jede Schicht endet
Ein Tunnel endet an seinem eigenen Gegenüber, ein Tor-Kreis an einem Exit-Relay. Nur HTTPS erreicht die Website, deshalb bleibt ein unverschlüsseltes Formular lesbar.
Ein VPN und ein Tor-Kreis verschlüsseln deinen Datenverkehr jeweils für einen Teil der Strecke. Beide hören an einem Gegenüber ihrer eigenen Wahl auf zu verschlüsseln. HTTPS ist die Schicht, die die Website selbst erreicht, und keine Menge Tunneling davor verwandelt das Absenden eines unverschlüsselten Formulars in ein geschütztes. Jede Schicht bis zu dem Punkt zu verfolgen, an dem sie endet, macht das offensichtlich.
Drei Schichten, drei verschiedene Endpunkte
Ein herkömmliches VPN beendet seinen Tunnel am VPN-Server. Alles zwischen deinem Gerät und diesem Server liegt im Tunnel, alles danach nicht. Ein Tor-Kreis verhält sich mit einem anderen Gegenüber genauso und verlässt das Netz an einem Exit-Relay, das deine Anfrage an das Ziel weiterleitet.
TLS endet an der Website. Das Zertifikat, das du geprüft hast, bindet einen Hostnamen an einen Schlüssel, den die Website kontrolliert, und die Sitzungsschlüssel existieren zwischen deinem Browser und diesem Server. Dieser Endpunkt liegt jenseits sowohl des VPN-Servers als auch des Tor-Exits.
Die drei Schichten haben also drei verschiedene Vertrauensgrenzen, und eine Anfrage durchläuft alle drei nacheinander. Eine zu stärken sagt nichts über die anderen, und die letzte ist die einzige, an der das Ziel beteiligt ist.
Was der letzte Sprung offenlegt
Nutzt die Anwendung einfaches HTTP, ist der Inhalt hinter dem Exit für jeden lesbar, der diesen Sprung betreibt. Der vorherige Tunnel hat seine Aufgabe perfekt erfüllt und ist einfach nicht mehr da. Anmeldedaten, die in ein HTTP-Formular getippt werden, liegen genau an dem Punkt offen, an dem der Schutz endete.
| Layer | Terminates at | Who can read the request there |
|---|---|---|
| VPN tunnel | The VPN server you selected | The operator of that server, and anyone who can compel them |
| Tor circuit | An exit relay chosen by the network | The exit relay operator, for traffic that is not otherwise protected |
| HTTPS | The website's own TLS endpoint | The site itself, and no intermediary on the path |
Bei korrekt geprüftem HTTPS kann eine Zwischenstelle auf dem Weg den Inhalt der Anwendung weder lesen noch still verändern. Sie sieht weiterhin, dass du dich verbunden hast, wann und zu welcher Adresse, weil die Paketköpfe routbar sein müssen. Vertraulichkeit des Inhalts und Metadaten über die Verbindung sind verschiedene Eigenschaften, und nur die erste liefert TLS.
Die Kontoidentität ist wieder eine dritte Sache. Wer sich in ein Konto einloggt, gibt sich gegenüber diesem Dienst zu erkennen, unabhängig davon, welche Exit-Adresse du verwendet hast, der Exit schützt also den Netzweg und nicht das Konto. Dieser Unterschied übersteht jede Anzahl von Schichten davor. Der Wechsel des Exits ändert nie, was eine angemeldete Sitzung verrät. Der Dienst wusste, wer du bist, bevor das erste Paket abging.
Nichts an dieser Anordnung bricht, wenn man einen zweiten Tunnel hinzufügt. Was sich ändert, ist welcher Beobachter den ersten Sprung sieht, nicht ob der letzte Sprung verschlüsselt ist.
Die Reihenfolge ändert die Beobachter, nicht den Endpunkt
Ein VPN und Tor zu verketten ist ein legitimer Weg, zu ändern, wer auf Netzebene was sieht. Tor über ein VPN laufen zu lassen verbirgt vor deinem Zugangsnetz, dass du Tor nutzt, während ein VPN über Tor deine Adresse vor dem VPN-Anbieter verbirgt. Beide Reihenfolgen sind in öffentlicher Dokumentation beschrieben und beide haben Kompromisse bei Leistung und Fehlerverhalten.
Keine der Reihenfolgen verschiebt den TLS-Endpunkt. In beiden Fällen prüft der Browser weiterhin ein Zertifikat für den angeforderten Hostnamen, und in beiden Fällen sendet eine HTTP-Adresse ihren Inhalt weiterhin ungeschützt hinter dem letzten Relay. Die Zusammensetzung ändert die Beobachterliste; sie ändert nicht die Schichtenzahl am Ziel.
Deshalb geht es bei Ratschlägen zum Verketten meist um Bedrohungsmodelle und nicht um Sicherheit im Allgemeinen. Eine längere Kette ist keine stärkere Version derselben Sache, und sie ersetzt nicht das Protokoll, das die Anwendung gewählt hat.
curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief
Beide Befehle zeigen die Schicht, auf die es am Ziel ankommt. Der zweite gibt das ausgehandelte Protokoll aus, ohne einen Tunnel einzubeziehen. Keiner sagt dir etwas über den Exit, den du benutzt hast.
Halte die Prüfung am Laufen, während du Fehler suchst
Eine Zertifikatswarnung ist eine Information über die Verbindung, die du gleich aufbaust. Sie kann eine Namensabweichung, ein Uhrproblem, eine nicht vertrauenswürdige Kette oder einen Abfangversuch bedeuten. Eine dauerhafte Ausnahme hinzuzufügen, weil ein VPN verbunden ist, entfernt das einzige Signal, das diese Fälle unterschieden hätte.
Die Funktionen für sichere Verbindungen in Tor Browser und seine Warnungen existieren aus demselben Grund, und sie abzuschalten, damit eine Seite lädt, tauscht einen sichtbaren Fehler gegen einen unsichtbaren. Lässt sich eine Website ohne Ausnahme nicht erreichen, ist die ehrliche Schlussfolgerung, dass die Verbindung nicht prüfbar ist, nicht dass der Tunnel sie sicher gemacht hat.
Verschlüsselung sagt auch nichts über Absicht. Eine gültige HTTPS-Verbindung zu einer täuschenden Website liefert deine Daten mit perfekter Vertraulichkeit an diese Website. Prüfe die Adresse und was du absendest, nicht nur ob das Schloss vorhanden ist.
Onion-Dienste sind ein wirklich anderes Modell. Sie werden über das Tor-Netz ohne einen gewöhnlichen öffentlichen Exit erreicht, was nicht dasselbe ist wie der Zugriff auf eine öffentliche Website über Tor. Behandle das als eigenen Fall mit eigenen Erwartungen und nicht als stärkere Version desselben Besuchs.
Die Regel, die jede Konfiguration übersteht, ist kurz. Halte die Browserprüfung intakt. Beurteile jede Schicht danach, wo sie tatsächlich endet.