Ist ein fehlgeschlagener VPN-Handshake wirklich ein Downgrade-Angriff?

Ein Handshake, der mit einem Fehler endet, fühlt sich wie ein Angriff an, bis man die Meldung ansieht, und meistens ist es Arithmetik: kein gemeinsames Angebot, ein abgelaufenes Zertifikat oder ein Paket, das nie ankam. Ein Downgrade-Angriff ist etwas Bestimmtes: ein Angreifer, der beide Seiten zu schwächerem Verhalten drängt, als sie gewählt hätten, und er hinterlässt andere Spuren. Jeden Fehlschlag als Böswilligkeit zu behandeln, lässt Sie nach einem Opfer suchen, das es vielleicht nicht gibt, während ein echtes Downgrade als Konfigurationsfehler zu behandeln das schwächere Ergebnis stehen lässt. Die beiden Fehler kosten unterschiedlich viel, und nur einer ist billig zu korrigieren.

Was ein Downgrade-Angriff tatsächlich ändert

Das Ziel ist nicht, die Verschlüsselung zu brechen, und nicht, einen Schlüssel zu erraten. Es ist, die Aushandlung so zu beeinflussen, dass beide Seiten auf einer älteren Version oder einem schwächeren Algorithmus landen, mit dem der Angreifer umgehen kann, oder dass eine Seite glaubt, die andere unterstütze nur das.

Was sich ändert, ist die Vereinbarung, nicht die Authentifizierung. Kann der Angreifer das Angebot unbemerkt verändern, können die Peers den Handshake dennoch abschließen und sich weiterhin gegenseitig authentifizieren, mit Parametern, die der Angreifer bevorzugt. Deshalb ist die interessante Frage, ob die Aushandlung selbst durch Integritätsschutz abgedeckt ist.

Warum die Aushandlung selbst authentifiziert werden muss

TLS 1.3 macht diesen Schutz explizit. Ein Client, der die neuere Version angeboten hat, kann einen Server erkennen, der still zurückgefallen ist, weil der Zufallswert des Servers ein festes Muster trägt, wenn er 1.2 oder niedriger aushandelt, und der Client muss beim Anblick abbrechen. Das vollständige Transkript ist außerdem durch die Finished-Nachrichten abgedeckt, sodass eine Änderung irgendwo in der Aushandlung später scheitert, statt still durchzugehen.

Ältere Protokollversionen hatten schwächere Geschichten, und genau deshalb zählen die Fallback-Regeln. Ein TLS 1.0-Endpunkt in derselben Konfiguration ist kein Downgrade-Angriff; er ist ein erlaubtes Ergebnis, das Sie zugelassen haben. Die Unterscheidung ist, ob das schwächere Ergebnis aus einer geschützten Entscheidung kam oder aus einem ungeschützten Pfad, den ein Vermittler beeinflussen konnte. Formuliert man es so, lösen sich die meisten Vorfälle in eine Konfigurationsfrage auf.

IKEv2 verhält sich anders, ruht aber auf derselben Idee. Das Angebot wird in einem Austausch übertragen, der später beide Peers authentifiziert, sodass eine Middlebox, die die Algorithmen umschreibt, die Authentifizierung bricht, statt sie zu lenken. Der Kontrollkanal von OpenVPN schützt seine Aushandlung mit TLS und nutzt diesen Kanal dann, um die Chiffren des Datenkanals zu vereinbaren, weshalb die Logzeile des Kontrollkanals die interessante ist.

Konfigurierte Kompatibilität ist kein Angriff

Ein Administrator kann ältere Optionen bewusst zulassen, um einen dokumentierten Client zu unterstützen, und diese Entscheidung ist in der Konfiguration sichtbar. Ein Angreifer kann diese Konfiguration nicht erzeugen; er kann nur einen Pfad ausnutzen, der ihm Einfluss auf das Angebot erlaubt.

Die gefährliche Reparatur ist die, die den Beweis für den Unterschied beseitigt. Jede Legacy-Option zu aktivieren, die Zertifikatsprüfung zu deaktivieren oder jede Chiffre zu akzeptieren, damit ein Fehler verschwindet, erweitert, worauf der Endpunkt sich einlässt, und entfernt die Prüfungen, die das schwächere Ergebnis gemeldet hätten.

Wenn Sie eine alte Option behalten müssen, nennen Sie den Grund und den Client im Konfigurationskommentar und beschränken Sie die Option dann auf das Profil, das sie braucht. Eine auf einen Listener begrenzte Kompatibilitätsausnahme ist prüfbar; eine global angewandte ist nur ein schwächerer Standard, von dem niemand weiß, dass er ihn gewählt hat.

Lesen Sie den Fehlschlag, bevor Sie eine Ursache benennen

Bewahren Sie die genaue Fehlermeldung, die Client- und Serverversionen und den Zeitpunkt vor jeder Änderung. Dann ordnen Sie zu: Waren sich die Peers über ein Angebot uneinig, ist der Paketpfad gescheitert, oder hat eine Seite einen Parameter abgelehnt, den sie früher akzeptiert hat?

Eine Angebotsabweichung nennt meist die betroffenen Versionen oder Algorithmen und scheitert jedes Mal an derselben Stelle. Ein Routing- oder MTU-Problem bleibt hängen oder läuft in ein Timeout und variiert oft mit dem Netzwerk. Ein abgelaufenes Zertifikat erzeugt einen Prüf- statt einen Aushandlungsfehler.

Nichts davon ist ein Beweis für einen Angreifer. Beim ersten Fehlschlag eine böswillige Ursache zuzuweisen ist der Fehler, weil es den deterministischen Fehler verbirgt, der morgen wieder scheitert.

Bestätigen Sie, was tatsächlich gewählt wurde

Lesen Sie nach jeder Korrektur das ausgehandelte Ergebnis, statt darauf zu vertrauen, dass die Verbindung zustande kam. Eine Verbindung, die gelingt, weil die Prüfung entfernt wurde, ist das Ergebnis, das Sie vermeiden wollten. Die beiden folgenden Befehle zeigen die gewählte Version und Chiffre für einen TLS-vorgelagerten Endpunkt sowie die Kontrollkanalzeile aus einem OpenVPN Server-Log.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Vergleichen Sie das Ergebnis mit der Konfiguration, die Sie beabsichtigt haben, nicht mit dem, was jetzt verbindet. Ist die gewählte Version älter als das erlaubte Minimum, sind das Profil oder die Fallback-Liste die Stelle zum Nachsehen, und die Antwort ist, diese Liste zu korrigieren, statt einen Angriff zu erklären und alles darum herum neu zu bauen.