OpenVPN: tls-ciphersuites und tls-version-min – was jede Option durchsetzt

Drei verschiedene Fakten werden in den meisten OpenVPN-TLS-Diskussionen zu einer Zeile zusammengefasst: was der Client-Build kann, was das Profil erlaubt und was die Sitzung tatsächlich ausgehandelt hat. Eine kurze TLS-1.3-Suite-Liste beantwortet nur die mittlere Frage halbwegs und sagt nichts über die Untergrenze der Protokollversion. Gehen Sie die Prüfungen unten der Reihe nach durch und halten Sie bei der ersten an, die nicht standhält, denn jede spätere Prüfung setzt voraus, dass die früheren geklärt sind.

Prüfen Sie den Build, bevor Sie irgendeine Liste lesen

Eine Konfigurationsdirektive kann einem Binary keine Protokollunterstützung hinzufügen, die es nicht besitzt. Beginnen Sie mit dem Versionsbanner, das die einkompilierte Krypto-Bibliothek nennt:

openvpn --version

Ein 2.6-Build, der gegen OpenSSL gelinkt ist, akzeptiert sowohl tls-cipher als auch tls-ciphersuites. Ein Build gegen mbed TLS hat überhaupt keine TLS-1.3-Suite-Auswahl, und das 2.6-Handbuch kennzeichnet tls-ciphersuites als OpenSSL-Option. Wird der Server mit einem anderen Backend neu gebaut, kann dasselbe Profil sein Verhalten ändern, ohne dass sich eine einzige Zeile der Konfiguration ändert.

Führen Sie openvpn --show-tls aus, solange Sie hier sind, und bewahren Sie die Ausgabe auf. Sie ist das Inventar, mit dem Sie später vergleichen, und es kostet wenig, sie zu erfassen, bevor jemand beginnt, Profile zu bearbeiten.

Schreiben Sie das Banner und die Liste ins Änderungsticket, nicht in ein Chatfenster. Wenn zwei Personen darüber streiten, ob ein Client in sechs Wochen eine Suite anbieten könnte, klärt die erfasste Ausgabe das in einer Zeile.

Versionsgrenzen getrennt von Cipher-Listen halten

Im 2.6-Handbuch sind das drei Steuerelemente, nicht eines:

• tls-cipher legt die Cipher-Policy für TLS 1.2 und älter fest und wird an OpenSSLs Cipher-Liste übergeben;
• tls-ciphersuites wählt TLS-1.3-Suiten aus;
• tls-version-min und tls-version-max begrenzen die Protokollversionen, die die Verbindung verwenden darf.

Eine sorgfältig zurechtgeschnittene TLS-1.3-Suite-Liste beweist also nichts darüber, dass eine ältere Version noch erlaubt ist. Wenn die Vorgabe „nur TLS 1.3“ lautet, trägt die Versionsuntergrenze sie, und die Suite-Liste verengt nur die Auswahl innerhalb dieser Untergrenze:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Dieses Paar erledigt zwei Aufgaben. Löscht man eine der Zeilen, setzt die andere weniger durch, als Sie denken — genau der Fehler, den diese ganze Prüfung abfangen soll.

Der Datenkanal ist ein vierter Regler. data-ciphers handelt die symmetrische Verschlüsselung innerhalb des Tunnels aus, und sein Ergebnis sagt nichts über die TLS-Version des Kontrollkanals. AES-256-GCM in der Sitzungszusammenfassung zu sehen, ist in keiner Richtung ein Beleg für TLS 1.3.

show-tls als lokales Inventar lesen

--show-tls zählt die Suiten auf, die die Krypto-Bibliothek unterstützt, gegen die dieses Binary gelinkt wurde, und zwar in Präferenzreihenfolge. Es ist kein Bericht vom Gateway. Das Handbuch sagt ausdrücklich, dass die Liste aus der lokalen Bibliothek stammt; ein Laptop mit OpenSSL 3.x und ein Router mit einem älteren Build geben also unterschiedliche Listen aus, während sie mit demselben Server sprechen.

Angenommen, ein Client unterstützt die Suiten A, B und C, und eine Sitzung wählt B. Das belegt nichts darüber, ob der Server A oder C erlaubt, und nichts darüber, ob B seine einzige zulässige Wahl ist. Halten Sie die drei Zeilen auseinander, und die meisten verwirrenden TLS-Threads lösen sich von selbst.

Das Inventar lohnt sich trotzdem. Wenn eine Sitzung scheitert, zeigt der Vergleich der Bibliotheksliste mit der Profilliste, ob der Client überhaupt eine Chance hatte, anzubieten, was der Server wollte. Er zeigt auch, ob eine Backend-Änderung TLS_CHACHA20_POLY1305_SHA256 still aus dem Pool entfernt hat, auf den ältere Clients angewiesen sind — die Art von Regression, die sich als eine Handvoll Nutzer zeigt, die keine Verbindung bekommen, während alle anderen nichts merken.

Das Gateway nach etwas fragen, das es beantworten kann

Wenn Sie den Dienst administrieren, prüfen Sie die effektive Konfiguration der laufenden Instanz statt einer Datei auf der Festplatte. OpenVPN wurde vielleicht mit einem anderen --config-Pfad gestartet, zieht vielleicht Includes ein und wurde seit der Änderung vielleicht nicht neu gestartet. Die Policy des laufenden Daemons ist das, worauf Clients treffen.

Wenn Sie ihn nicht administrieren, fragen Sie den Betreiber nach unterstützten Client-Anforderungen oder einem abgegrenzten Abnahmetest. Ein abgelehnter Versuch ist nicht automatisch eine abgelehnte Suite: eine Versionsuntergrenze, Zertifikats-Identitätsprüfungen wie remote-cert-tls oder eine Nichtübereinstimmung von tls-auth gegenüber tls-crypt können den Austausch beenden, bevor die Suite-Auswahl überhaupt zählt. Lesen Sie den Serverfehler, bevor Sie die Client-Liste ändern, denn „Handshake fehlgeschlagen“ deckt vier verschiedene Ursachen ab, und nur eine davon ist eine Cipher-Nichtübereinstimmung.

openssl s_client auf den VPN-Port zu richten, reproduziert die Frage ebenfalls nicht. Der Kontrollkanal läuft innerhalb von OpenVPNs eigenem Framing, also testet eine rohe TLS-Sonde ein anderes Protokoll auf einem Port, der etwas anderes erwartet. Jede daraus gezogene Schlussfolgerung betrifft die Sonde, nicht den Tunnel.

Zwei Ergebnisse festhalten und getrennt halten

Eine frische, erlaubte Sitzung erzeugt eine Kontrollkanal-Zeile, die die Protokollversion und die gewählte Chiffre nennt, sowie eine separate Datenkanal-Zeile, die die Tunnel-Chiffre nennt. Erfassen Sie beide mit der Client-Version und dem Profilnamen, und notieren Sie, welche Serverinstanz geantwortet hat:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Lesen Sie dann die beiden Zeilen aus dieser Datei statt aus dem Gedächtnis. Das Paar ist der Beleg; ein Suite-Name allein ist eine Präferenz, und die Versionsgrenze ist eine separate Aussage darüber, was der Server ablehnt.

Führen Sie die Prüfungen in dieser Reihenfolge aus. Bestätigen Sie Build und Backend mit --version. Erfassen Sie --show-tls, bevor Sie etwas ändern. Nennen Sie die erforderliche Versionsuntergrenze getrennt von der Suite-Liste. Bestätigen Sie die effektive Policy der laufenden Instanz mit deren Eigentümer. Beobachten Sie eine erlaubte Sitzung und, wenn der Plan es zulässt, einen abgelehnten Versuch mit einer älteren Version. Halten Sie die Ergebnisse von Kontrollkanal und Datenkanal als getrennte Feststellungen fest.

Wenn ein erforderlicher Client ein neues Minimum nicht erfüllen kann, treffen Sie diese Migrations- oder Ausnahmeentscheidung ausdrücklich, statt still eine unabhängige Abnahmeregel zu senken, damit der Rollout fertig aussieht.