OpenVPN EC vs ED : pourquoi ces noms ne forment pas une échelle de force

Placez ec, ed, ecdh, ecdsa, auth et une liste de chiffrements TLS côte à côte dans un même profil : le fichier commence à ressembler à un sélecteur de puissance à six positions. Il ne l’est pas. Chaque nom répond à une question différente, et deux profils qui diffèrent sur l’un d’eux ne sont pas forcément plus forts ou plus faibles l’un que l’autre. Trier les noms selon le travail qu’ils font prend environ cinq minutes et évite la plupart des mauvaises modifications que les gens font sur une configuration qui fonctionne.

Le tri ci-dessous part de la confusion elle-même, puis s’élargit vers les parties d’un profil qui décident réellement de ce qui protège votre trafic. Chaque section prend à son tour une erreur de lecture et montre à quoi le nom est vraiment rattaché.

Deux lettres, deux questions différentes

La paire qui provoque le plus de débats est EC et ED, et le débat suppose souvent qu’il s’agit de réponses rivales à une même question. Ils ne sont même pas sur le même axe. EC décrit une famille de mathématiques : la cryptographie sur courbe elliptique, où la sécurité vient de la difficulté d’un logarithme discret sur une courbe et non dans un grand corps fini.

ED décrit une forme de courbe à l’intérieur de cette famille. Les courbes Twisted Edwards sont une représentation choisie pour la vitesse et pour la résistance à plusieurs erreurs d’implémentation, et Ed25519 est le nom que les gens veulent généralement dire. La courbe n’est pas un concurrent de la cryptographie sur courbe elliptique ; c’est une façon d’écrire une courbe elliptique. Lire ED comme "l’EC plus récent et plus fort" est le premier mauvais virage, et tout ce qui suit tend à être faux dans la même direction.

Signer et échanger sont deux tâches distinctes

Une fois la question de la famille réglée, les noms restants se répartissent en deux colonnes qui ne se remplacent jamais. Une colonne signe, l’autre s’accorde sur un secret partagé.

EdDSA et ECDSA signent tous deux, mais ce sont des schémas différents avec des formats de clé différents, donc un certificat émis pour l’un n’est pas utilisable comme l’autre. EdDSA est défini pour un petit ensemble de courbes ; P-256 n’en fait pas partie, ce qui explique qu’un certificat P-256 se vérifie avec ECDSA et jamais avec Ed25519.

La colonne d’échange n’a pas d’équivalent nommé EdDH. L’accord éphémère sur une clé Curve25519 est X25519, et c’est de l’ECDH avec une courbe particulière, exactement comme avec P-256. Ed25519 désigne strictement le schéma de signature, même si le nom est utilisé librement pour l’échange parce que les deux courbes sont liées : la forme Edwards utilisée pour signer et la forme Montgomery utilisée pour X25519 décrivent le même groupe sous-jacent.

Pourquoi un profil EC n’a pas de fichier dh

Un fichier dh contient des paramètres générés à l’avance pour Diffie-Hellman en corps fini, et ces paramètres existent parce qu’un grand nombre premier et un générateur doivent venir de quelque part. Un échange sur courbe elliptique n’en a pas besoin : la courbe nommée est le jeu de paramètres, et les deux côtés le connaissent déjà. C’est toute la raison pour laquelle un profil EC peut omettre la directive.

Deux situations produisent encore une ligne dh dans un profil qui semble moderne par ailleurs. La première est un second écouteur ou un pair plus ancien qui négocie réellement des groupes en corps fini. La seconde est un texte résiduel copié depuis un modèle de l’époque RSA et jamais supprimé. Un profil qui nomme une courbe pour l’échange et charge encore un fichier dh de 2048 bits n’est pas plus sûr pour autant ; il transporte un artefact inutilisé.

TLS 1.3 a retiré l’échange de clés du nom

Comparez TLS_AES_256_GCM_SHA384 avec TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 et le nom plus court ressemble à une régression. C’est un renommage, et la raison est structurelle : TLS 1.3 a supprimé le RSA statique et l’échange de clés Diffie-Hellman en corps fini, si bien qu’un échange éphémère sur courbe elliptique est la seule option non-PSK qui reste. Le nommer dans chaque suite reviendrait à répéter le même fait une douzaine de fois.

Le type de certificat a disparu du nom pour une raison liée. En 1.3, le certificat authentifie la signature de la poignée de main, pas l’accord de clés, il ne sélectionne donc plus la suite. C’est aussi pourquoi une liste de chiffrements séparée existe pour 1.3 dans la configuration : les suites ont été renommées et réorganisées, pas affaiblies.

Une conséquence mérite d’être dite clairement. ECDHE est un algorithme d’échange de clés et jamais un chiffrement. Une suite décrite comme "elliptique" dit quelque chose sur la façon dont les deux pairs sont arrivés à une clé partagée, et rien du tout sur ce qui chiffre ensuite la charge utile.

auth authentifie les paquets, pas les charges utiles

La directive auth sélectionne l’empreinte HMAC qui authentifie les paquets, et sa valeur par défaut historique est SHA1. Avec un chiffrement de données non AEAD, OpenVPN calcule l’empreinte sur le texte chiffré et l’ajoute, un montage chiffrer-puis-MAC qui rend la manipulation du remplissage peu pratique.

Le mythe ici est que monter auth à SHA512 durcit le tunnel. Cela n’augmente pas la force du chiffrement, et si le chiffrement de données négocié est un mode AEAD comme AES-256-GCM, l’empreinte n’est pas appliquée du tout aux paquets de données. L’étiquette GCM les authentifie déjà, et la valeur auth reste pour le HMAC du canal de contrôle et pour tout chiffrement non AEAD encore utilisé.

La directive compte donc, mais elle compte à un endroit plus étroit que ne le suggère sa position dans le fichier. Vérifier quel chiffrement a réellement été négocié vous dit si elle s’applique ou non.

Lisez le profil par colonne, pas par rang

Trois questions séparent proprement les couches, et chacune trouve sa réponse dans une partie différente de la session négociée. Quel chiffrement protège la charge utile ? Quelle étiquette ou empreinte se porte garante de chaque paquet, et le chiffrement utilisé en exige-t-il seulement une ? Quel certificat a clos la poignée de main, et le canal de contrôle est-il en plus protégé par tls-auth ou tls-crypt ?

Rien dans l’étiquette EC ou ED ne tranche aucune de ces trois questions, et un nom de suite à lui seul n’en tranche aucune non plus. Le résultat négocié est la seule preuve, alors lisez-le plutôt que de déduire la force du vocabulaire :

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

La première commande vous dit quel schéma de signature votre certificat utilise réellement, et c’est le seul moyen fiable de savoir si vous tournez en ECDSA ou en Ed25519. La seconde montre la ligne de canal de contrôle que le client a journalisée pour la session, y compris la version de TLS et la suite retenue. Si une modification de profil ne peut pas être justifiée par l’une de ces deux sorties, c’est probablement un changement de nom et non de propriété.