Sind die Daten über VPN sicher, wenn man sich in einem ausbeuterischen WLAN befindet

Question

Oft hört/liest man, dass mit SSL oder besser VPN die eigenen Daten sicher sind, auch wenn das WLAN nicht sicher ist.

Ich verstehe nicht viel von Handshakes und SSL- oder VPN-Sicherheit, aber ich konnte mir immer kaum vorstellen, dass man eine sichere Verbindung über eine bösartige Verbindung hinweg aufbauen kann. Da ich jetzt häufiger öffentliche WLANs benutze, wird dies für mich zu einem Problem, also habe ich angefangen, ein bisschen zu lesen, aber die Antworten sind immer etwas vage. Vielleicht ist ein Beispiel also der bessere Weg, um zu erklären/fragen, was ich meine.

Nehmen wir an, Sie befinden sich in einer Bibliothek mit unverschlüsseltem WLAN. Jemand hat eine Stunde vor meiner Ankunft in der Bibliothek sein Pineapple 5 mitgebracht und fälscht die SSID dieses Netzwerks.

Eine Stunde später komme ich an, starte meinen Laptop und logge mich in das WLAN der Bibliothek ein. Ich weiß nicht, ob es den gleichen Namen hat und die Zielseite ähnlich aussieht, aber der Hacker hat mich auf seine gefälschte Seite umgeleitet. Er hat jetzt mit Sicherheit meine Login-Daten für die Bibliothek - was zwar schlecht ist, aber nicht meine Hauptsorge.

Ich sehe, dass ich nun eine bestehende Verbindung zum WLAN habe. Nun starte ich mein Cyberghost VPN und verbinde mich damit alles klappt problemlos.

Sind die Passwörter, die über diesen Kanal laufen, sicher?

In meinem Kopf wäre die Antwort: „Wie um Himmels Willen soll das sicher sein??“ Wenn der Hacker die Verhandlung lesen kann, etwa „Verwenden Sie AES, 256 Bit, und der private Schlüssel ist XXX“, kann er die Verschlüsselung „auflösen“ und den Klartext meiner Kommunikation lesen, oder übersehe ich etwas?

Answer 1

Das ist tatsächlich eine gute Frage und nicht so einfach, wie sie aussieht. Die tatsächliche Antwort darauf, ob ein VPN vor Man-In-The-Middle-Angriffen (MiTM) schützt, hängt stark von der Implementierung der VPN-Software ab und davon, an welcher Stelle der Kommunikationskette sich der Angreifer Zugang verschafft hat.

In dem einfachen Fall, den Sie beschrieben haben, ist das Element, das Sie vergessen haben, das vom VPN-Server zurückgegebene Zertifikat. Der Client kann den öffentlichen Schlüssel des Servers überprüfen, indem er die ausstellende Zertifizierungsstelle konsultiert. Mit diesem öffentlichen Schlüssel kann er mit dem VPN-Server kommunizieren, aber nur der VPN-Server verfügt über den privaten Schlüssel, der zum Dekodieren der Nachricht erforderlich ist. Der MiTM-Angreifer hat also keine Ahnung, was vor sich geht.

HTTPS funktioniert ähnlich wie VPN und stellt daher ebenfalls einen guten Schutz dar, obwohl es keinen perfekten Schutz gibt.

Nützliche Ressourcen:

• Primzahlen schützen Ihre verschlüsselten Nachrichten – so geht's
• Geheimer Schlüsselaustausch (Video)

Visuelle Beschreibung des Vorgangs:

Answer 2

Sie sagen, Ihr VPN verwendetSSL, daher ist der Vorgang relativ einfach und es gibt viele Lernressourcen.

Erstens gibt es beidesasymmetrischUndsymmetrische Verschlüsselungbeteiligt. Um den Schlüssel für die symmetrische Verschlüsselung sicher auszuhandeln, wird die asymmetrische Verschlüsselung verwendet.

Asymmetrische Verschlüsselung ist im Allgemeinen sehr rechenintensiv (RSAsogar noch mehr als moderne elliptische Kurven-Verschlüsselung). Es ist nicht geeignet, um die eigentlichen Daten einer VPN-Verbindung zu übertragen. Dies geschieht mit einer schnellen symmetrischen Verschlüsselung wieAES.

Beim Herstellen einer einseitig authentifizierten (kein Client-Zertifikat) RSA SSL/TLS-Verbindung gehen Sie wie folgt vor:

1. Der Client kennt entweder das VPN-Server-Zertifikat direkt oder das ausstellende Zertifikat vorab. Dies ist erforderlich, um festzustellen, ob dem Server vertraut werden kann.
2. Der Client sendet die Client-Hello-Nachricht, die eine Liste unterstützter Chiffren und mehr enthält.
3. Der Server antwortet mit der Server-Hello-Nachricht, die die zu verwendende Verschlüsselung usw. und das Zertifikat des Servers (enthält den öffentlichen Schlüssel) sowie etwaige Zwischenzertifikate enthält.
4. Der Client sendet den symmetrischen Schlüssel mit asymmetrischer Verschlüsselung (unter Verwendung des öffentlichen Schlüssels des Servers – ja, dies ist sicher und kann nur mit dem öffentlichen Schlüssel des Servers entschlüsselt werden.PrivatSchlüssel).
5. Da der symmetrische Schlüssel beiden Seiten bekannt ist, kann nun die Datenverbindung hergestellt werden.

Der symmetrische Schlüssel läuft normalerweise ab und wird erneuert, wenn die Verbindung über einen längeren Zeitraum aktiv bleibt.

Es gibt eine andere Art des Schlüsselaustauschs, genanntDiffie-Hellman (DH). Es ist komplizierter, aber das Endergebnis ist das gleiche. Es wird auch verwendet mitmit elliptischen Kurven (ECDH).

Wenn ein Angreifer versucht, den Schlüsselaustausch anzuhängen, müsste er das Zertifikat des Servers ersetzen, um den symmetrischen Schlüssel entschlüsseln zu können. Dies kann vom Client erkannt werden, da das Ersatzzertifikat des Angreiferswürde man nicht trauen.