OpenVPN: TLS-basierte VPN-Architektur

OpenVPN verwendet zwei getrennte Kanäle: den Steuerkanal und den Datenkanal. Der Steuerkanal übernimmt Authentifizierung, Sitzungsaufbau und den Austausch der Konfiguration mithilfe von TLS. Der Datenkanal transportiert den eigentlichen VPN-Datenverkehr, der mit einer symmetrischen Chiffre verschlüsselt wird, die über den Steuerkanal ausgehandelt wurde. Durch diese Trennung kann OpenVPN das gesamte TLS-Ökosystem für die Schlüsselverwaltung nutzen.

Der Steuerkanal von OpenVPN führt eine vollständige TLS-Sitzung aus. Beide Seiten authentifizieren sich mithilfe von X.509-Zertifikaten, die von einer gemeinsamen CA signiert wurden. TLS übernimmt den Schlüsselaustausch, die Zertifikatsvalidierung und die Aushandlung der Parameter für die Chiffre des Datenkanals. Da TLS ECDHE unterstützt, bietet der Steuerkanal Perfect Forward Secrecy: Die Schlüssel des Datenkanals können selbst mit dem CA-Schlüssel nicht aus einer aufgezeichneten Sitzung rekonstruiert werden.

Die Verschlüsselung des Datenkanals wird über den TLS-Steuerkanal ausgehandelt. OpenVPN 2.4 und höher verwenden standardmäßig AES-256-GCM, eine AEAD-Chiffre, die Vertraulichkeit und Integrität in einem einzigen Vorgang gewährleistet. Frühere Versionen verwendeten AES-256-CBC und HMAC-SHA256 getrennt voneinander. AEAD-Modi werden bevorzugt, weil sie eine separate MAC-Prüfung überflüssig machen und vor Padding-Oracle-Angriffen schützen.

Die Option tls-crypt verpackt die gesamte TLS-Sitzung einschließlich des Client Hello in einen symmetrischen, mit HMAC authentifizierten Umschlag, der einen Pre-Shared Key verwendet. Dadurch können nicht authentifizierte Clients nicht einmal einen TLS-Handshake beginnen; ihre ersten Pakete werden stillschweigend verworfen. Dies schützt den OpenVPN-Server vor TLS-basierten DDoS-Verstärkungsangriffen und verbirgt, dass ein VPN-Server ausgeführt wird.

Die ältere Option tls-auth fügt den Paketen des TLS-Steuerkanals einen HMAC-Tag hinzu, verschlüsselt sie jedoch nicht. Dadurch wird das Einschleusen von Paketen verhindert, der TLS-Handshake bleibt für Beobachter aber sichtbar. tls-crypt verschlüsselt und authentifiziert den Umschlag des Steuerkanals und bietet dadurch sowohl DoS-Schutz als auch Schutz vor Verkehrsanalyse. tls-crypt ist die empfohlene moderne Option; tls-auth ist zugunsten von tls-crypt-v2 veraltet.

OpenVPN authentifiziert Clients mithilfe von X.509-Zertifikaten, die von der Certificate Authority des VPN signiert wurden. Jeder Client erhält ein eindeutiges Zertifikat und einen privaten Schlüssel. Der Server überprüft die Zertifikatskette und kann optional eine Certificate Revocation List (CRL) prüfen, um widerrufene Zertifikate abzulehnen. Durch den Widerruf eines Zertifikats wird der Zugriff eines Clients sofort entzogen. Bei PSK-basierten Systemen würde eine Schlüsseländerung dagegen alle Clients betreffen.

OpenVPN kann über UDP (Standard und empfohlen) oder TCP ausgeführt werden. UDP vermeidet das TCP-over-TCP-Problem, bei dem Paketverluste sowohl auf der TCP-Ebene als auch auf der VPN-Anwendungsebene doppelte Übertragungen auslösen und die Leistung erheblich verschlechtern. Einige Netzwerke blockieren jedoch UDP. Wenn OpenVPN auf TCP-Port 443 ausgeführt wird, lassen sich Firewalls umgehen, die nur HTTPS-Datenverkehr zulassen. Bei Paketverlusten geht dies allerdings zulasten der Leistung.

OpenVPN arbeitet im tun-Modus (Routing) oder im tap-Modus (Bridging). Der tun-Modus erstellt eine Point-to-Point-IP-Netzwerkschnittstelle, die IP-Pakete zwischen dem Client und dem VPN-Netzwerk weiterleitet. Der tap-Modus erstellt eine Ethernet-Bridge-Schnittstelle, die Ethernet-Frames einschließlich Broadcasts und Nicht-IP-Protokollen überträgt. Der tun-Modus ist effizienter und für die meisten VPN-Anwendungsfälle geeignet; der tap-Modus wird zum Überbrücken von Netzwerksegmenten oder für Nicht-IP-Protokolle benötigt.

OpenVPN-Server können verbindenden Clients automatisch Konfigurationsdirektiven übermitteln. Häufige Push-Direktiven sind push "route 10.0.0.0 255.0.0.0" (fügt auf dem Client eine Route hinzu), push "dhcp-option DNS 10.0.0.1" (legt den DNS-Server fest) und push "redirect-gateway def1" (leitet den gesamten Client-Datenverkehr durch das VPN). Dadurch wird die Verwaltung der Client-Konfiguration zentralisiert, ohne die einzelnen Client-Konfigurationsdateien ändern zu müssen.

OpenVPN erreicht Perfect Forward Secrecy durch TLS ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) im Steuerkanal. Für jede TLS-Sitzung wird ein neues ephemeres Schlüsselpaar verwendet, sodass der Sitzungsschlüssel nicht aus dem privaten Langzeitschlüssel des Serverzertifikats abgeleitet werden kann. Selbst wenn verschlüsselter Datenverkehr heute aufgezeichnet und das Serverzertifikat später erlangt wird, lassen sich vergangene Sitzungen nicht entschlüsseln.

OpenVPN 2.5 hat die Blowfish-Chiffre (BF-CBC) als veraltet gekennzeichnet, die historisch als Standard verwendet wurde. BF-CBC verwendet eine Blockgröße von 64 Bit und ist bei langen Sitzungen anfällig für SWEET32-Geburtstagsangriffe. Moderne OpenVPN-Versionen verwenden standardmäßig AES-256-GCM. OpenVPN 2.5 hat außerdem Nicht-AEAD-Chiffren im Datenkanal als veraltet gekennzeichnet und die Mindestanforderungen an die TLS-Version verschärft, wodurch TLS 1.0 und 1.1 nicht mehr unterstützt werden.

Was ist die Hauptfunktion des OpenVPN-Steuerkanals?

Zusammenfassung von OpenVPN: Der Steuerkanal verwendet TLS für Authentifizierung und Chiffren-Aushandlung, der Datenkanal verwendet eine ausgehandelte AEAD-Chiffre (standardmäßig AES-256-GCM), tls-crypt verpackt TLS, um nicht authentifizierte Handshakes zu verhindern, ECDHE liefert Forward Secrecy, die Client-Authentifizierung erfolgt zertifikatsbasiert mit CRL-Widerruf, UDP wird aus Leistungsgründen gegenüber TCP bevorzugt und der tun-Modus wird für Anwendungsfälle mit IP-Routing bevorzugt.