OpenVPN tls-ciphersuites face à tls-version-min : ce que chacun impose

Trois faits différents se retrouvent réduits à une seule ligne dans la plupart des discussions OpenVPN sur TLS : ce que votre compilation client sait faire, ce que le profil autorise et ce que la session a réellement négocié. Une courte liste de suites TLS 1.3 ne répond qu'à moitié à la question du milieu, et elle ne dit rien du plancher de version du protocole. Passez les vérifications ci-dessous dans l'ordre et arrêtez-vous à la première qui ne tient pas, car chaque vérification ultérieure suppose que les précédentes sont réglées.

Vérifiez la compilation avant de lire la moindre liste

Une directive de configuration ne peut pas ajouter à un binaire un support de protocole qu'il n'a pas. Commencez par la bannière de version, qui nomme la bibliothèque cryptographique compilée :

openvpn --version

Une compilation 2.6 liée à OpenSSL accepte à la fois tls-cipher et tls-ciphersuites. Une compilation avec mbed TLS n'a aucune sélection de suites TLS 1.3, et le manuel 2.6 marque tls-ciphersuites comme une option OpenSSL. Si le serveur est reconstruit avec un autre backend, le même profil peut changer de comportement sans qu'une seule ligne de configuration change.

Pendant que vous y êtes, lancez openvpn --show-tls et conservez la sortie. C'est l'inventaire auquel vous comparerez plus tard, et il est peu coûteux de le capturer avant que quiconque commence à modifier des profils.

Écrivez la bannière et la liste dans le ticket de changement, pas dans une fenêtre de discussion. Quand deux personnes se disputent pour savoir si un client pourra proposer une suite dans six semaines, la sortie capturée tranche en une ligne.

Gardez les bornes de version séparées des listes de chiffrement

Dans le manuel 2.6, ce sont trois contrôles, pas un :

• tls-cipher fixe la politique de chiffrement pour TLS 1.2 et antérieur, et la transmet à la liste de chiffrements d'OpenSSL ;
• tls-ciphersuites sélectionne les suites TLS 1.3 ;
• tls-version-min et tls-version-max bornent les versions de protocole que la connexion peut utiliser.

Une liste de suites TLS 1.3 soigneusement élaguée ne prouve donc rien quant au fait qu'une version plus ancienne reste autorisée. Si l'exigence est « TLS 1.3 uniquement », c'est le plancher de version qui la porte, et la liste de suites ne fait que restreindre les choix à l'intérieur de ce plancher :

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

Cette paire remplit deux fonctions. Supprimer l'une des lignes laisse l'autre imposer moins que vous ne le pensez, et c'est précisément la défaillance que toute cette vérification existe pour attraper.

Le canal de données est un quatrième contrôle. data-ciphers négocie le chiffrement symétrique à l'intérieur du tunnel, et son résultat ne dit rien de la version TLS du canal de contrôle. Voir AES-256-GCM dans le résumé de session n'est pas une preuve concernant TLS 1.3, dans un sens comme dans l'autre.

Lisez show-tls comme un inventaire local

--show-tls énumère les suites prises en charge par la bibliothèque cryptographique contre laquelle ce binaire est lié, par ordre de préférence. Ce n'est pas un rapport de la passerelle. Le manuel précise explicitement que la liste vient de la bibliothèque locale, ce qui signifie qu'un portable sous OpenSSL 3.x et un routeur doté d'une compilation plus ancienne imprimeront des listes différentes tout en parlant au même serveur.

Supposez qu'un client prenne en charge les suites A, B et C et qu'une session choisisse B. Cela n'établit rien sur le fait que le serveur autorise A ou C, ni sur le fait que B soit son seul choix autorisé. Gardez les trois lignes séparées, et la plupart des fils TLS confus se résolvent d'eux-mêmes.

L'inventaire vaut quand même la peine d'être conservé. Quand une session échoue, comparer la liste de la bibliothèque à celle du profil indique si le client avait la moindre chance de proposer ce que le serveur voulait. Cela montre aussi si un changement de backend a silencieusement retiré TLS_CHACHA20_POLY1305_SHA256 du pool sur lequel comptent les clients plus anciens — le type de régression qui se manifeste par une poignée d'utilisateurs incapables de se connecter pendant que tous les autres ne remarquent rien.

Posez à la passerelle une question à laquelle elle peut répondre

Si vous administrez le service, inspectez la configuration effective de l'instance en cours plutôt qu'un fichier sur disque. OpenVPN a peut-être été démarré avec un autre chemin --config, peut charger des inclusions et n'a peut-être pas été redémarré depuis la modification. La politique du démon en cours d'exécution est celle que rencontrent les clients.

Si vous ne l'administrez pas, demandez à l'opérateur les exigences client prises en charge ou un test d'acceptation encadré. Une tentative rejetée n'est pas automatiquement une suite rejetée : un plancher de version, des contrôles d'identité de certificat comme remote-cert-tls, ou une incompatibilité entre tls-auth et tls-crypt peuvent mettre fin à l'échange avant même que la sélection de suite n'ait d'importance. Lisez l'erreur du serveur avant de changer la liste du client, car « handshake failed » couvre quatre causes différentes et une seule d'entre elles est une incompatibilité de chiffrement.

Pointer openssl s_client vers le port VPN ne reproduit pas non plus la question. Le canal de contrôle s'exécute à l'intérieur du propre encadrement d'OpenVPN, donc une sonde TLS brute teste un autre protocole sur un port qui attend autre chose. Toute conclusion qui en découle porte sur la sonde, pas sur le tunnel.

Enregistrez deux résultats et gardez-les séparés

Une session autorisée fraîche produit une ligne de canal de contrôle nommant la version du protocole et le chiffrement sélectionné, et une ligne distincte de canal de données nommant le chiffrement du tunnel. Capturez les deux avec la version du client et le nom du profil, et notez quelle instance du serveur a répondu :

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

Lisez ensuite les deux lignes dans ce fichier plutôt que de mémoire. La paire constitue la preuve ; un nom de suite seul est une préférence, et la borne de version est une affirmation distincte sur ce que le serveur refuse.

Effectuez les vérifications dans cet ordre. Confirmez la compilation et le backend avec --version. Capturez --show-tls avant de changer quoi que ce soit. Énoncez le plancher de version requis séparément de la liste de suites. Confirmez la politique effective de l'instance en cours avec son propriétaire. Observez une session autorisée et, si le plan le permet, une tentative refusée avec une version plus ancienne. Enregistrez les résultats du canal de contrôle et du canal de données comme des constats distincts.

Si un client requis ne peut pas atteindre un nouveau minimum, prenez cette décision de migration ou d'exception explicitement au lieu d'abaisser en silence une règle d'acceptation sans rapport pour que le déploiement paraisse terminé.