OpenVPN EC vs. ED: Warum die Namen keine Stärkeleiter sind

Setzen Sie ec, ed, ecdh, ecdsa, auth und eine TLS-Verschlüsselungsliste nebeneinander in ein Profil, und die Datei beginnt wie ein Stärkeregler mit sechs Stellungen auszusehen. Ist sie aber nicht. Jeder Name beantwortet eine andere Frage, und zwei Profile, die sich in einem davon unterscheiden, sind nicht zwangsläufig stärker oder schwächer als das andere. Die Namen nach ihrer Aufgabe zu sortieren dauert etwa fünf Minuten und verhindert die meisten schlechten Änderungen, die Leute an einer funktionierenden Konfiguration vornehmen.

Die folgende Sortierung beginnt bei der Verwirrung selbst und arbeitet sich dann nach außen zu den Teilen eines Profils vor, die tatsächlich entscheiden, was Ihren Datenverkehr schützt. Jeder Abschnitt nimmt nacheinander eine Fehldeutung auf und zeigt, woran der Name wirklich hängt.

Zwei Buchstaben, zwei verschiedene Fragen

Das Paar, das die meisten Diskussionen auslöst, ist EC und ED, und die Diskussion geht meist davon aus, dass sie konkurrierende Antworten auf eine Frage sind. Sie liegen nicht einmal auf derselben Achse. EC beschreibt eine mathematische Familie: Kryptografie mit elliptischen Kurven, bei der die Sicherheit aus der Schwierigkeit eines diskreten Logarithmus auf einer Kurve stammt und nicht in einem großen endlichen Körper.

ED beschreibt eine Kurvenform innerhalb dieser Familie. Twisted-Edwards-Kurven sind eine Darstellung, die wegen ihrer Geschwindigkeit und ihrer Widerstandsfähigkeit gegen mehrere Implementierungsfehler gewählt wurde, und Ed25519 ist der Name, den man meist meint. Die Kurve ist kein Konkurrent der Kryptografie mit elliptischen Kurven; sie ist eine Art, eine elliptische Kurve zu schreiben. ED als "das neuere, stärkere EC" zu lesen ist die erste falsche Abzweigung, und alles danach ist meist in dieselbe Richtung falsch.

Signieren und Austauschen sind getrennte Aufgaben

Sobald die Familienfrage geklärt ist, teilen sich die übrigen Namen in zwei Spalten, die einander nie ersetzen. Die eine Spalte signiert, die andere einigt sich auf ein gemeinsames Geheimnis.

EdDSA und ECDSA signieren beide, sind aber unterschiedliche Verfahren mit unterschiedlichen Schlüsselformaten, daher ist ein für das eine ausgestelltes Zertifikat nicht als das andere verwendbar. EdDSA ist für eine kleine Menge von Kurven definiert; P-256 gehört nicht dazu, weshalb sich ein P-256-Zertifikat mit ECDSA und nie mit Ed25519 verifizieren lässt.

Die Austauschspalte hat kein Gegenstück namens EdDH. Die ephemere Einigung über einen Curve25519-Schlüssel ist X25519, und das ist ECDH mit einer bestimmten Kurve, genau wie bei P-256. Ed25519 bezeichnet streng genommen das Signaturverfahren, auch wenn der Name locker für den Austausch verwendet wird, weil die beiden Kurven verwandt sind: die Edwards-Form für das Signieren und die Montgomery-Form für X25519 beschreiben dieselbe zugrunde liegende Gruppe.

Warum ein EC-Profil keine dh-Datei hat

Eine dh-Datei enthält vorab erzeugte Parameter für Diffie-Hellman im endlichen Körper, und diese Parameter existieren, weil eine große Primzahl und ein Generator irgendwoher kommen müssen. Ein Austausch auf elliptischen Kurven braucht sie nicht: die benannte Kurve ist der Parametersatz, und beide Seiten kennen ihn bereits. Das ist der ganze Grund, warum ein EC-Profil die Direktive weglassen kann.

Zwei Situationen erzeugen immer noch eine dh-Zeile in einem Profil, das sonst modern aussieht. Die erste ist ein zweiter Listener oder ein älterer Peer, der tatsächlich Gruppen im endlichen Körper aushandelt. Die zweite ist übrig gebliebener Text, der aus einer Vorlage aus der RSA-Zeit kopiert und nie entfernt wurde. Ein Profil, das eine Kurve für den Austausch nennt und trotzdem eine 2048-Bit-dh-Datei lädt, ist dadurch nicht sicherer; es trägt ein ungenutztes Artefakt mit sich.

TLS 1.3 hat den Schlüsselaustausch aus dem Namen entfernt

Vergleichen Sie TLS_AES_256_GCM_SHA384 mit TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, und der kürzere Name wirkt wie eine Herabstufung. Es ist eine Umbenennung, und der Grund ist struktureller Art: TLS 1.3 hat statisches RSA und den Diffie-Hellman-Schlüsselaustausch im endlichen Körper entfernt, sodass ein ephemerer Austausch auf elliptischen Kurven die einzige verbleibende Nicht-PSK-Option ist. Ihn in jeder Suite zu nennen würde dieselbe Tatsache ein Dutzend Mal wiederholen.

Der Zertifikatstyp verschwand aus einem verwandten Grund aus dem Namen. In 1.3 authentisiert das Zertifikat die Handshake-Signatur, nicht die Schlüsselvereinbarung, und wählt daher nicht mehr die Suite. Deshalb gibt es in der Konfiguration eine eigene Verschlüsselungsliste für 1.3: Die Suiten wurden umbenannt und neu geordnet, nicht geschwächt.

Eine Konsequenz verdient es, klar ausgesprochen zu werden. ECDHE ist ein Schlüsselaustauschalgorithmus und niemals eine Verschlüsselung. Eine als "elliptisch" beschriebene Suite sagt etwas darüber, wie die beiden Peers zu einem gemeinsamen Schlüssel gelangten, und nichts darüber, was anschließend die Nutzlast verschlüsselt.

auth authentisiert Pakete, nicht Nutzlasten

Die Direktive auth wählt den HMAC-Digest, der Pakete authentisiert, und ihr historischer Standardwert ist SHA1. Bei einer Datenverschlüsselung ohne AEAD berechnet OpenVPN den Digest über den Chiffretext und hängt ihn an, eine Encrypt-then-MAC-Anordnung, die Manipulationen am Padding unpraktisch macht.

Der Mythos hier ist, dass es den Tunnel härte, auth auf SHA512 zu erhöhen. Es erhöht nicht die Stärke der Verschlüsselung, und wenn die ausgehandelte Datenverschlüsselung ein AEAD-Modus wie AES-256-GCM ist, wird der Digest überhaupt nicht auf Datenpakete angewandt. Das GCM-Tag authentisiert sie bereits, und der auth-Wert bleibt für das HMAC des Steuerkanals und für jede noch verwendete Verschlüsselung ohne AEAD übrig.

Die Direktive ist also wichtig, aber an einer engeren Stelle wichtig, als ihre Position in der Datei vermuten lässt. Zu prüfen, welche Verschlüsselung tatsächlich ausgehandelt wurde, sagt Ihnen, ob sie überhaupt gilt.

Lesen Sie das Profil nach Spalte, nicht nach Rang

Drei Fragen trennen die Schichten sauber, und jede wird von einem anderen Teil der ausgehandelten Sitzung beantwortet. Welche Verschlüsselung schützt die Nutzlast? Welches Tag oder welcher Digest bürgt für jedes Paket, und braucht die verwendete Verschlüsselung überhaupt eines? Wessen Zertifikat hat den Handshake abgeschlossen, und ist der Steuerkanal zusätzlich durch tls-auth oder tls-crypt geschützt?

Nichts an der Bezeichnung EC oder ED entscheidet eine dieser drei Fragen, und ein Suite-Name allein entscheidet auch keine davon. Das ausgehandelte Ergebnis ist der einzige Beleg, also lesen Sie es, statt die Stärke aus dem Vokabular abzuleiten:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Der erste Befehl sagt Ihnen, welches Signaturverfahren Ihr Zertifikat tatsächlich verwendet, und das ist der einzige verlässliche Weg zu wissen, ob Sie ECDSA oder Ed25519 einsetzen. Der zweite zeigt die Steuerkanalzeile, die der Client für die Sitzung protokolliert hat, einschließlich der TLS-Version und der Suite, auf die man sich geeinigt hat. Lässt sich eine Profiländerung nicht durch eine dieser beiden Ausgaben begründen, ist sie wahrscheinlich eine Änderung an einem Namen und nicht an einer Eigenschaft.