OpenVPN-Protokoll: Steuerkanal-Chiffre gegen Datenkanal-Chiffre

Eine Protokollzeile, die DHE-RSA-AES256-SHA nennt, ist keine Zusammenfassung der gesamten Verbindung. Sie gehört zum TLS-Handshake, der den Steuerkanal schützt, und der Verkehr innerhalb des Tunnels kann ganz anders verschlüsselt sein. Sie als Datenciffre des VPN auszugeben, ist der Fehler, den es zu vermeiden gilt.

Zwei Ergebnisse sind wichtig, und sie beantworten verschiedene Fragen. Eines ist die ausgehandelte TLS-Suite für den Steuerkanal; das andere ist die Datenciffre für die Pakete, die der Tunnel befördert.

Zwei Ergebnisse, zwei Fragen

Der Steuerkanal trägt den Handshake und die Verwaltungsnachrichten zwischen den Peers. Seine Chiffre wird vom TLS-Stack gewählt, daher folgt der Name den TLS-Konventionen. Der Datenkanal trägt den Nutzerverkehr und wird durch OpenVPNs eigene Chiffreaushandlung konfiguriert.

Entscheide, welche Frage du beantwortest, bevor du eine der beiden Zeilen liest. Ob der Tunnel verschlüsselt ist und ob der Handshake stark ist, sind nicht dieselbe Frage.

Ein Protokollauszug, der beide Zeilen zeigt, ist der nützliche. Lies die Steuerzeile für TLS-Version und Suite und die Datenzeile für den Algorithmus, der die Nutzlast tatsächlich schützt.

Den TLS-Suite-Namen im eigenen Kontext entschlüsseln

In einem historischen OpenSSL-Namen wie DHE-RSA-AES256-SHA beschreibt jede Komponente eine andere Entscheidung. DHE ist die ephemere Diffie-Hellman-Schlüsselvereinbarung, RSA ist das Authentifizierungsverfahren, AES256 ist AES-256 im CBC-Modus für TLS-Records, und SHA ist der Record-MAC auf SHA-1-Basis.

Die letzte Komponente ist kein Zertifikat-Fingerabdruck, und sie als einen zu lesen, ist ein häufiger Fehler. Der Name nennt auch nicht von sich aus die Protokollversion, denn TLS 1.3 verwendet eine ganz andere Namenskonvention. TLS_AES_256_GCM_SHA384 folgt dieser neueren Form, bei der der abschließende Hash Teil des Suite-Aufbaus ist und keine MAC-Wahl. Wende die komponentenweise Lesart nur auf den älteren Namensstil an.

Die OpenSSL-Suite-Referenz ordnet diese Namen ihren Definitionen zu, falls eine Komponente unbekannt ist.

Das Ergebnis des Datenkanals für den beförderten Verkehr lesen

Lies für den beförderten Verkehr die Datenkanalzeile aus derselben Sitzung. Eine data-ciphers-Liste in der Konfiguration ist eine erlaubte Menge und kein Beweis dafür, dass ein bestimmter Algorithmus ausgehandelt wurde. Das Protokoll hält die Wahl fest; die Konfiguration dokumentiert das Angebot.

Eine AEAD-Chiffre wie AES-GCM bringt ihre eigene Integritätsprüfung mit, daher ist ein separates Datenkanal-HMAC nicht Teil dieses Pfades.

Die Anweisung auth wertet weder TLS noch Zertifikate noch die Datenciffre auf. Sie wählt für die Teile des Protokolls, die noch einen verwenden, einen Digest aus, und bei einer AEAD-Datenciffre gibt es keinen separaten Daten-HMAC zu konfigurieren.

Identitätsprüfungen aus dem Chiffre-Ergebnis heraushalten

Signaturalgorithmus des Zertifikats, Prüfung der Vertrauenskette und Prüfung des Peer-Namens sind drei weitere Eigenschaften, über die ein Chiffrename nichts aussagt. Ein abgelaufenes Zertifikat schlägt fehl, egal wie stark die Suite ist. Ein nicht passender Servername schlägt ebenso fehl. Eine Digest-Einstellung im Profil zu korrigieren, behebt keines von beiden.

Halte diese Prüfungen in den Prüfnotizen neben dem Chiffre-Ergebnis fest und verschmelze sie nicht damit.

Die ausgehandelten Ergebnisse aus der aktuellen Sitzung festhalten

Nimm die Ergebnisse aus der aktuellen Verbindung und halte die Client- und Serverversionen dazu fest. Ein reines Anhängeprotokoll kann die Zeile einer älteren Sitzung enthalten, und sie als aktuell zu zitieren, lässt ein behobenes Problem fortbestehen.

Für eine Richtlinienprüfung gib dem Konfigurationseigentümer die ausgehandelte TLS-Version und Suite, die gewählte Datenciffre und die Zertifikatsprüfungseinstellungen zusammen. Ändere diese Ebene und lies dann ein frisches Protokoll, um die neuen ausgehandelten Werte zu bestätigen.