Erreur de chiffrement TLS sous OpenVPN : comparez d’abord les deux pairs

Une erreur « aucun chiffrement commun » ressemble à un réglage à changer, et le réglage que la plupart des gens changent est le mauvais. OpenVPN garde des politiques distinctes pour le canal de contrôle qui effectue la poignée de main TLS et pour le canal de données qui transporte les paquets dans le tunnel, et l’erreur nomme le premier alors que les gens modifient le second. Comparer ce que chaque pair autorise, dans le bon ordre, transforme les suppositions en deux ou trois décisions : version, puis liste de suites, puis identifiants.

Se tromper dans cet ordre peut coûter une heure passée à ajouter un nom AES à une liste qui n’a jamais été consultée.

Deux listes de chiffrement, et une seule casse la poignée de main

Le canal de contrôle négocie une session TLS, et sa politique s’écrit avec tls-cipher pour TLS 1.2 et tls-ciphersuites pour TLS 1.3. Le canal de données se configure à part avec data-ciphers, où une divergence produit une connexion qui s’établit puis ne fait plus passer le trafic. Les deux produisent des erreurs qui mentionnent des chiffrements, d’où la confusion. Une poignée de main qui ne se termine jamais désigne le canal de contrôle, tandis qu’un tunnel établi qui perd des paquets désigne le canal de données.

Lisez le message entier plutôt que la première ligne. Une divergence de version, une suite manquante, un algorithme de signature de certificat que le pair rejette et un échec de vérification du nom d’hôte finissent tous en erreur TLS, et un seul d’entre eux concerne votre liste de suites. Distinguer ces catégories, c’est l’essentiel du diagnostic.

Comparez les versions avant les suites

Un pair limité à TLS 1.2 et un pair qui exige 1.3 ne partagent aucune version, et aucune chaîne de chiffrement ne comble cela. Notez tls-version-min et tls-version-max des deux côtés, ou les valeurs par défaut des compilations utilisées, car la politique OpenSSL d’une distribution peut relever le plancher sans qu’aucune option OpenVPN ne le dise. Si un côté est un équipement ou un client tiers, sa fenêtre est ce que son micrologiciel autorise. Ce n’est que lorsque les fenêtres se chevauchent qu’une comparaison de suites veut dire quelque chose.

Ces relevés devraient aussi nommer les binaires réels. Un openvpn en ligne de commande sur votre portable n’est pas forcément le client qui gère un profil importé.

Les listes TLS 1.2 et TLS 1.3 ne se mélangent pas

Les noms de suites TLS 1.2 ressemblent à ECDHE-RSA-AES256-GCM-SHA384 et vont dans tls-cipher, qui accepte une chaîne de chiffrement OpenSSL. Les suites TLS 1.3 s’appellent comme TLS_AES_256_GCM_SHA384 et vont dans tls-ciphersuites ; en ajouter une à la chaîne 1.2 ne configure pas la liste 1.3, et l’analyseur peut accepter le texte sans jamais le faire correspondre. Un filtre correct pour une version ne dit rien de l’autre. Notez pour quelle version chaque liste est prévue.

openvpn --show-tls affiche ce que la compilation locale prend en charge, et c’est un inventaire, pas une promesse : le pair distant peut ne pas autoriser ces suites, et le profil actif peut ne pas les activer. Servez-vous-en pour écarter une compilation qui ne peut pas proposer de suite du tout, puis comparez les listes configurées.

Prouvez la négociation sur une connexion neuve

Une poignée de main réussie est la seule preuve qui compte, et elle doit venir du vrai client avec le vrai profil. Augmentez la verbosité du serveur, connectez-vous une fois et lisez dans le journal la version de protocole et la suite négociées au lieu de supposer que la première valeur offerte l’a emporté. Confirmez ensuite le canal de données séparément avec du trafic dans le tunnel, car une poignée de main qui fonctionne et un canal de données défaillant sont deux réparations différentes. Répétez après chaque changement de configuration, car un profil client obsolète est un faux négatif courant.

S’il n’existe aucune configuration commune approuvée, la réponse est une mise à niveau ou un plan de migration, pas une politique affaiblie. Baisser tls-version-min, désactiver la vérification ou activer toutes les suites anciennes supprime le rejet sans satisfaire l’exigence de sécurité qui l’a produit.

Notez la version négociée, la suite et le chiffrement de données dans le ticket de changement. La prochaine personne qui rencontrera une erreur TLS partira de ce relevé plutôt que d’une chaîne de chiffrement trouvée dans un message de forum.