Was der Tunnel verschlüsselt und was lesbar bleibt

Ihr Tunnel läuft, ein Tab zeigt ein grünes Schloss, und eine einfache HTTP-Seite in einem anderen Tab warnt weiterhin, dass die Verbindung nicht sicher ist. Diese Kombination verwirrt Menschen, weil die beiden Schutzmaßnahmen unterschiedliche Strecken abdecken. Ein VPN schützt den Verkehr zwischen seinen eigenen Endpunkten, und jenseits des Ausgangs ist der Verkehr wieder gewöhnlich. HTTPS schützt eine Verbindung bis zur Website. Wer diese beiden Tatsachen nebeneinanderlegt, erklärt damit die meisten Fragen dazu, was ein VPN tatsächlich verbirgt.

Was der Tunnel tatsächlich abdeckt

Zwischen dem Client und dem VPN-Peer sieht ein Beobachter verschlüsselte Bytes statt einer lesbaren Anfrage. Das deckt den Abschnitt ab, den der Tunnel durchquert, also meist den Teil, den Sie nicht kontrollieren. Er reicht nicht bis zur Strecke zwischen VPN-Ausgang und Website, weil der Tunnel am Ausgang endete. Die Bytes sind ab dem Moment wieder lesbar, in dem der Tunnel endet. Nichts daran ist eine Fehlkonfiguration.

Der Ausgang ist eine Maschine, die entschlüsselt und weiterleitet, und genau dafür ist ein VPN da. Alles, was sie weiterleitet, ist für sie in der Form sichtbar, in der sie es empfangen hat, weshalb eine einfache HTTP-Anfrage ab dem Ausgang Klartext bleibt.

Lesen Sie das als Eigenschaft und nicht als Mangel. Verschlüsselung ist auf einen Pfad begrenzt, und der Pfad endet dort, wo der Dienst beginnt.

Schlüssel, Nonces und Integrität in einfachen Worten

Laufender Verkehr wird mit symmetrischer Kryptografie geschützt, und beide Seiten leiten das Schlüsselmaterial während des Handshakes ab oder beziehen es. Authentifizierte Verschlüsselung, allgemein beschrieben in RFC 5116, liefert Vertraulichkeit und Integrität in einer Konstruktion. Der Empfänger weist veränderte Bytes zurück, statt sie nur nicht lesen zu können, und genau das vergessen Menschen, wenn sie glauben, Verschlüsselung bedeute Durcheinanderbringen.

Die Schlüssel stammen aus diesem Austausch, nicht aus dem beim Login eingegebenen Passwort. Das Passwort authentifiziert eine Identität, und danach etabliert das Protokoll Sitzungsmaterial. Ephemerer Schlüsselaustausch liefert Forward Secrecy, sodass eine aufgezeichnete Sitzung unlesbar bleibt, selbst wenn später ein langfristiger Schlüssel durchsickert.

Eine große Zahl in einer Spezifikation beantwortet keine dieser Fragen, und Zahlen über miteinander unverbundene Algorithmen zu vergleichen ist keine Rangliste. Fragen Sie stattdessen, was der Schlüsselaustausch leistet.

Wo der Tunnel endet

Der Endpunkt, der den Tunnel beendet, kann lesen, was er weiterleitet. Das gilt für ein Unternehmens-Gateway, einen kommerziellen Anbieter und einen selbst gehosteten Server gleichermaßen. Das ist das Design, kein Defekt darin. Starke Kryptografie kann einen kompromittierten Endpunkt nicht daran hindern, Klartext zu lesen, der bei ihm ankommt, denn der Endpunkt ist der Ort, an dem der Schutz endet.

HTTPS reicht über diesen Punkt hinaus, weshalb eine Website auch ohne VPN in einem feindlichen Netz sicher sein kann. Die beiden Schutzmaßnahmen überlappen sich im ersten Abschnitt, und nur eine von ihnen setzt sich nach dem Ausgang fort.

Deshalb ist es auch kein Test des Tunnels, die Zertifikatsprüfung abzuschwächen, damit eine Verbindung funktioniert. Das deaktiviert einen anderen Schutz und lässt Sie mit weniger zurück, als Sie zu Beginn hatten.

Warum Anonymität ein anderes Produkt ist

Adressen, Timing und Volumen bleiben außerhalb des Tunnels beobachtbar. Ein Beobachter kann sehen, dass Verkehr zu einem VPN-Endpunkt fließt, ungefähr wie viel und wann. Der Inhalt kann unlesbar sein, während das Muster noch informativ ist.

Der Anbieter sitzt außerdem an einem anderen Ort als Ihr eigenes Netz, was ein Wechsel des Beobachters und keine Beseitigung der Beobachtung ist. Cookies, Logins und Konto-Kennungen funktionieren genau wie zuvor, weil der Tunnel nie versprochen hat, sie zu verändern.

Wählen Sie einen Anbieter nach seiner Protokollierungsrichtlinie und Gerichtsbarkeit, wenn das die Anforderung ist, und lesen Sie dann die Richtlinie selbst. Marketingseiten beantworten diese Frage selten so, dass jemand sie prüfen kann.

Prüfen Sie Tunnel und Website getrennt

Prüfen Sie zuerst den Tunnel, damit Sie wissen, welchen Schutz Sie testen. Prüfen Sie dann den eigenen Transport der Website und vergleichen Sie die beiden Ergebnisse, statt anzunehmen, dass eines das andere bedingt. Ein Tunnel, der einfaches HTTP befördert, und eine Website, die HTTPS ausliefert, tun beide genau das, wofür sie konfiguriert wurden.

Führen Sie die Prüfungen gegen einen Host aus, den Sie testen dürfen, und lesen Sie die Ausgabe statt der Zusammenfassung.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Wenn der Tunnel läuft und die Website HTTPS ist, haben Sie zwei Schutzmaßnahmen im ersten Abschnitt und eine im zweiten. Wenn die Website einfaches HTTP ist, ist der zweite Abschnitt für alle darauf lesbar, einschließlich des Ausgangs, der die Anfrage weiterleitete. Zu wissen, welche der beiden fehlt, ist die ganze Diagnose, und dafür braucht es zwei Befehle statt eines neuen Clients.