Warum AES-256 keine VPN-Verschlüsselungssuite beschreibt

Fragt man, welche Verschlüsselung ein VPN nutzt, kommt meist ein einziges Wort zurück: AES-256, oder ChaCha20, oder vielleicht WireGuard. Diese Antwort nennt eine Komponente einer Ebene, während das, was die Verbindung tatsächlich schützt, eine Menge von Algorithmen ist, die vier verschiedene Rollen erfüllen. Komponente und Anordnung zu verwechseln ist der häufigste Fehler in diesen Gesprächen, und er erzeugt Vergleiche, die sich nicht auflösen lassen.

Vier Aufgaben in einer Verbindung

Massenverschlüsselung verwandelt Klartext in Chiffrat für den Datenkanal, und ihr Schlüssel wird abgeleitet statt übertragen. Integritätsschutz erkennt Veränderungen, was eine eigene Aufgabe ist, auch wenn eine einzige Konstruktion beides leistet. Schlüsseletablierung erzeugt das gemeinsame Verkehrsmaterial, und Peer-Authentifizierung entscheidet, wer am anderen Ende sitzt. Fehlt eines davon, ist die Verbindung nicht sicher, egal wie stark das verbleibende Stück ist.

Manche Entwürfe legen zwei Rollen zusammen. AES-GCM und ChaCha20-Poly1305 sind authentifizierte Verschlüsselungskonstruktionen, daher kommen Vertraulichkeit und Integrität gemeinsam; AES-CBC nicht, es braucht einen separaten Message Authentication Code mit eigenem Schlüssel. Ein Proposal als Beutel unabhängiger Zahlen zu lesen, missdeutet daher die, die als Paare gedacht sind.

Die Rollen liegen zudem auf verschiedenen Ebenen, weshalb dasselbe Wort in zwei Produkten Unterschiedliches bedeuten kann. Eine Blockchiffre in ESP und eine Blockchiffre in TLS sind dieselbe Primitive in verschiedenen Verhandlungen mit verschiedenen Anforderungen. Deshalb kann das Zitieren einer Primitive ohne Modus und Ebene schlimmer sein, als gar nichts zu zitieren.

Warum ein Cipher-Name fast nichts sagt

Nimm den Ausdruck AES-256 einmal ernst: Er bezeichnet eine Blockchiffre und eine Schlüssellänge. Er sagt nichts über den Betriebsmodus, ob Integrität geboten wird, wie Schlüssel etabliert oder der Peer authentifiziert wurde. Zwei Produkte können beide AES-256 bewerben und sich in allem anderen unterscheiden, darunter eines mit unauthentifiziertem Modus und eines mit AEAD-Modus und modernem Schlüsselaustausch.

TLS 1.3 hat diese Trennung in den Standard gehoben, was für alle eine nützliche Korrektur ist, die das ältere Vokabular gelernt haben. Seine Cipher Suites nennen nur die AEAD und den Hash, während Schlüsselaustauschgruppen und Signaturalgorithmen als eigene Parameter verhandelt werden. Ein TLS-1.3-Suite-Name ist daher nicht direkt mit einem TLS-1.2-Suite-Namen vergleichbar, obwohl beide im selben Feld einer Konfigurationsdatei stehen. Wer die beiden Zeichenketten direkt vergleicht, zieht eine Schlussfolgerung, die das Protokoll nicht stützt. Lies auch die verhandelte Gruppe und die Signaturparameter, sonst bleibt der Vergleich unvollständig.

WireGuard wählt den entgegengesetzten Weg und entfernt die Verhandlung fast ganz: Das Protokoll schreibt eine feste Algorithmenmenge vor, also interoperieren zwei Implementierungen oder sie tun es nicht. Das ist eine legitime Entwurfsentscheidung, und sie bedeutet auch, dass die Frage, welche Suite WireGuard verhandelt, keine vergleichbare Antwort hat. Wer prüft, liest die Spezifikation einmal und prüft dann die Schlüsselbehandlung darum herum statt die Verhandlung.

Die Ebene bestimmt das Vokabular

Ein IPsec-Deployment verhandelt zweimal: ein IKE-Proposal für den Steuerkanal und einen ESP-Transform für die Daten, und beide dürfen sich unterscheiden. Das erste zu lesen und anzunehmen, es beschreibe das zweite, ist eine häufige Verwechslungsquelle bei einer Prüfung, weil die Konfigurationsdatei beide nennt und das interessante das zweite ist.

Ein Name, den eine Bibliothek bietet, ist nicht automatisch für einen anderen Datenpfad implementiert. Deshalb ist die Aussage, unser Produkt unterstütze AES-256, schwächer als sie klingt, und deshalb löst man ein Interoperabilitätsproblem meist, indem man die gepflegte Schnittmenge findet, statt auf beiden Seiten jeden Altalgorithmus zu aktivieren.

Die TLS-1.3-Spezifikation ist das klarste veröffentlichte Beispiel dieser Trennung, da sie die Suite als Paar definiert und den Rest in eigene Verhandlungen verschiebt. Ist diese Form vertraut, werden das IPsec-Proposal und die eine feste WireGuard-Menge als Varianten derselben Idee lesbar.

Das verhandelte Ergebnis lesen, dann aufhören

Ein konfiguriertes Proposal ist kein Beweis dafür, was zwei Peers gewählt haben. Die laufende Sitzung trägt die Antwort, und jede gängige Implementierung kann sie ohne Paketmitschnitt melden.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Lies in der Ausgabe die gewählten Algorithmen statt der angebotenen Liste. Ist die Antwort schwächer, als die Richtlinie es beabsichtigt, gehört die Korrektur in die Proposal-Konfiguration auf einer der Seiten, und eine Abweichung zeigt sich in modernen Implementierungen meist als fehlgeschlagene Verhandlung statt als stilles Downgrade.

Dann erinnere dich, was die Suite nicht abdeckt. Routen, Anwendungsberechtigungen, Protokollierung und Aufbewahrung sind eigene Entscheidungen mit eigener Prüfung, und eine kompatible kryptografische Anordnung sagt nichts darüber. Die Cipher-Diskussion lohnt sich, beantwortet aber eine engere Frage als die, die die meisten tatsächlich stellen.

Halte das Vokabular präzise, und die Argumentation wird kürzer. Eine Suite ist eine Menge von Rollen auf einer Ebene, ein Cipher ist eine Komponente, und das verhandelte Ergebnis ist das Einzige, was die Verbindung beschreibt, die du tatsächlich hast. Alles andere im Vergleich ist Dekoration.