Definition (Glossarkarte): tls-crypt-v2 ist der client-spezifische Control-Channel-Verschlüsselungsmodus von OpenVPN. Jeder Client erhält einen eindeutigen tls-crypt-Schlüssel (Kc) sowie eine umhüllte Kopie dieses Schlüssels (WKc), die mit einem gemeinsamen Serverschlüssel verschlüsselt ist. Beim Verbinden sendet der Client WKc in einem P_CONTROL_HARD_RESET_CLIENT_V3 Paket; der Server entpackt Kc, und beide Peers verschlüsseln anschließend die Control-Channel-Pakete mit dem client-spezifischen Schlüssel statt mit einem gemeinsamen Pre-Shared Key.

Diagram comparing pre-shared key VPN authentication concepts
Quelle: Wikimedia Commons — Lbutrico Pre-Shared Key

Wenn ein OpenVPN-Einstellungsbildschirm oder eine Anbieter-FAQ „tls-crypt-v2“ erwähnt, ist damit ein Schutzmechanismus für den Control Channel gemeint, kein Data-Channel-Cipher und kein eigenständiges VPN-Protokoll. Den Unterschied zu kennen, ist für große Flotten und gehostete VPN-Anbieter wichtig: klassische --tls-auth and --tls-crypt teilen einen Gruppenschlüssel über alle Clients und Server. Wird ein Peer kompromittiert, bietet dieser gemeinsame Schlüssel keinen sinnvollen DoS- und TLS-Stack-Schutz mehr für alle anderen. tls-crypt-v2 behält den serverseitigen Wrapping-Schlüssel gemeinsam, gibt jedem Client aber einen eigenen Kc.

Woher das Design stammt

OpenVPN dokumentiert die Funktion in doc/tls-crypt-v2.txt und in der vom Projekt generierten API-Dokumentation für Verschlüsselung des Steuerkanals (tls-crypt, tls-crypt-v2). Dasselbe client-spezifische Schema findet sich im Entwurf OpenVPN Wire Protocol unter „Client-spezifische Verschlüsselungsschlüssel“, wo ausdrücklich festgehalten wird, dass bestehende Implementierungen die Funktion tls-crypt-v2 nennen.

Die Begründung ist ebenso betrieblich wie kryptografisch. Gemeinsame Gruppenschlüssel laufen bei steigender Client-Anzahl schneller ab, und ein kompromittierter Laptop kann ein Massen-Re-Keying erzwingen. Indem der Kc jedes Clients unter einem Serverschlüssel verschlüsselt und der WKc mit dem Client ausgeliefert wird, können Betreiber einzelne Clients widerrufen oder rotieren, ohne einen einzigen gemeinschaftsweiten statischen Schlüssel neu verteilen zu müssen. Server akzeptieren weiterhin Legacy tls-crypt or tls-auth Clients während der Migration, weil der V3-Hard-Reset-Opcode den neuen Modus signalisiert.

SSL VPN topology showing client, network, and server roles
Quelle: Wikimedia Commons — SSL-VPN-Topologie

Auf hoher Ebene ist der Ablauf ein verschlüsseltes Cookie:

  1. Betreiber erstellen einen tls-crypt-v2 Server Schlüssel, der nur zum Ein- und Auspacken von Client-Schlüsseln verwendet wird.
  2. Für jeden Client erzeugen sie einen frischen Kc, packen ihn als WKc unter dem Serverschlüssel ein und übergeben Kc || WKc an den Client (häufig als PEM-Block mit der Überschrift BEGIN OpenVPN tls-crypt-v2 client key).
  3. Das erste Steuerpaket des Clients verwendet den Opcode P_CONTROL_HARD_RESET_CLIENT_V3 und enthält WKc.
  4. Der Server entschlüsselt WKc, lädt Kc, führt optional ein tls-crypt-v2-verify Skript anhand der Metadaten aus und beide Seiten verwenden danach Kc für den tls-crypt-artigen Schutz des Steuerkanals.

Optionale Metadaten im umschlossenen Blob können frühe Richtlinienprüfungen enthalten (beispielsweise Hinweise zur Client-Identität), sodass ein Server missbräuchliche Handshakes abbrechen kann, bevor er aufwändige TLS-Arbeit leistet. Dieser frühe Abbruch ist ein Grund, warum die Funktion für DoS-Resistenz in großen Multi-Tenant-Systemen beworben wird. Große VPN-Anbieter profitieren besonders, weil kompromittierte Kundenendpunkte nicht mehr automatisch einen einzelnen gemeinsamen tls-crypt-Gruppenschlüssel offenlegen, von dem alle anderen Kunden für die Filterung des Kontrollkanals abhängen.

Was tls-crypt-v2 schützt – und was nicht

tls-crypt-v2 verschlüsselt und authentifiziert Kontrollkanal Pakete: den TLS-Handshake-Verkehr, der Sitzungsschlüssel und Optionen aushandelt. Es ersetzt nicht die Datenkanal-Chiffre (AES-GCM, ChaCha20-Poly1305 und so weiter), wählt keine Exit-IPs und setzt keine No-Logs-Richtlinie um. Betrachten Sie es als Panzerung um die Steuerebene von OpenVPN, sodass unauthentifiziertes UDP-Rauschen und gestohlene Gruppenschlüssel gegen den TLS-Stack weniger nützlich sind.

Die Versionshinweise zu OpenVPN 2.7.8 (zusammengefasst von Linux Compatible am 7. Oktober 2026) zeigen ebenfalls, warum Robustheit rund um tls-crypt-v2 weiterhin wichtig ist: Ein Fix in 2.7.8 hinderte Clients daran, einer Peer-Anfrage zum erneuten Senden eines umhüllten Client-Schlüssels blind zu vertrauen, wenn kein Schlüsselmaterial verfügbar war. Italiens CRA-Politik behandelte diese Klasse von Problemen („bösartiger Server kann den Client stören“) als Robustheitsverschlechterung und nicht als CVE-würdigen Vertraulichkeitsbruch, aber Betreiber wollen den Patch dennoch auf jedem Client, der tls-crypt-v2 spricht.

Worin es sich von tls-auth und tls-crypt unterscheidet

  • tls-auth: Nur HMAC-Integrität für Kontrollpakete mit einem gemeinsamen statischen Schlüssel; verschlüsselt den Kontrollkanal nicht.
  • tls-crypt: Verschlüsselt und authentifiziert Kontrollpakete mit einem gemeinsamen Gruppenschlüssel.
  • tls-crypt-v2: Derselbe AEAD-artige Schutz des Steuerkanals wie bei tls-crypt, jedoch mit clientindividueller Kc plus vom Server umhüllten WKc-Cookies.

Alle drei betreffen den Steuerkanal. Sie mit dem Noise-Handshake von WireGuard oder mit IKEv2 zu verwechseln, ist ein häufiger Glossarfehler. WireGuard verwendet kein tls-crypt-v2; OpenVPN-Anwender, die andernorts WireGuard aktivieren, befinden sich auf einem völlig anderen Stack. Ebenso rüstet das Aktivieren von tls-crypt-v2 veraltete Datenkanal-Chiffren nicht magisch auf und behebt keine DNS-Leaks außerhalb des Tunnels.

Praktische Checkliste

  1. Wenn Sie einen Multi-Client-OpenVPN-Server oder eine Flotte eines VPN-Anbieters betreiben, bevorzugen Sie tls-crypt-v2 gegenüber einem einzelnen gemeinsamen tls-crypt-Schlüssel, damit ein verlorener Client nicht den gesamten Gruppenschlüssel vergiftet.
  2. Halten Sie den Server-Wrapping-Schlüssel offline gesichert und rotierbar; planen Sie, wie WKc-Dateien neu ausgestellt werden, wenn sich dieser Serverschlüssel ändert.
  3. Bestätigen Sie, dass Clients tatsächlich V3-Hard-Reset beherrschen (moderne OpenVPN-Builds), bevor Sie Legacy-tls-auth/tls-crypt auf dem Server deaktivieren.
  4. Verfolgen Sie OpenVPN 2.7.8+ hinsichtlich Robustheitskorrekturen für tls-crypt-v2, auch wenn eine Änderung keine CVE-ID hat.
  5. Denken Sie daran: Eine starke Umhüllung des Steuerkanals behebt weder ein wiederverwendetes Benutzerpasswort noch ein Phishing-Portal oder einen DNS-Leak außerhalb des Tunnels.

Kurz gesagt: tls-crypt-v2 ist OpenVPNs Antwort auf die Frage: „Wie behalten große Deployments die Verschlüsselung des Steuerkanals ohne einen katastrophalen gemeinsamen statischen Schlüssel?“ Lernen Sie das Cookie-Modell, halten Sie Datenkanal- und Richtlinienfragen getrennt und behandeln Sie die clientindividuelle Schlüsselhygiene als Teil des normalen VPN-Betriebs statt als exotische Option nur für Unternehmen.