Un vieux pair impose TLS 1.0 : encadrez l’exception, pas l’hôte

Un vieil appareil apparaît, échoue à se connecter, et la réparation qui semble la plus rapide est d’affaiblir tout l’hôte jusqu’à ce que la connexion réussisse. Cet échange est invisible sur le moment et permanent en pratique, car personne ne retire un plancher qui fonctionne enfin. Deux pannes très différentes créent la pression, et une seule concerne vraiment les chiffrements. Triez d’abord la panne, puis placez l’exception là où elle ne peut pas se propager.

Séparez la panne en deux avant de modifier une directive

Une ligne du journal du serveur sur l’absence de chiffrement commun, ou sur une version de protocole non prise en charge, vient du canal de contrôle : les deux extrémités n’ont pas réussi à s’accorder sur la manière de protéger la négociation elle-même. À l’inverse, la ligne du client indiquant qu’aucune méthode de vérification du certificat serveur n’est activée vient d’ailleurs entièrement, car ce client ne vérifie pas du tout qui a répondu. Changer un chiffrement de données ne fait rien pour le second cas, et ajouter un contrôle de rôle ne fait rien pour le premier.

Prenez la première ligne d’échec de chaque côté plutôt que la dernière avant la déconnexion, car la dernière est généralement une conséquence. Établissez ensuite quel fichier le client a réellement ouvert : un profil importé existe souvent deux fois sous des noms d’affichage différents, et modifier la copie que personne ne lit produit un non-changement convaincant. Un processus en cours conserve les réglages avec lesquels il a démarré, donc un fichier enregistré n’est pas un fichier chargé. Les commandes ci-dessous montrent la négociation du client à côté de la vue du serveur sur la même tentative.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Un second listener est l’endroit honnête pour un plancher plus faible

Quand l’appareil plafonne à TLS 1.0 avec un canal de données antérieur à 2.5, le serveur doit proposer un plancher plus bas pour le canal de contrôle et un chiffrement de données que l’ancien client reconnaît. La directive de repli existe précisément pour ce pair, tandis que la liste de chiffrements maintient les clients modernes sur des suites modernes. Les deux directives appartiennent au listener et non à un utilisateur ou à une connexion, et aucune option par client ne les resserre ensuite. C’est pourquoi un seul appareil ancien sur le port principal est une décision sur chaque pair qui le partage.

Là où la plateforme le permet, exécutez l’ancien listener comme sa propre instance sur un port séparé, autorisez ce port uniquement depuis l’adresse de l’appareil, et laissez le service principal tranquille. Notez pourquoi le second listener existe, dans le fichier qui porte sa configuration, car un nettoyage futur le lira sinon comme un débris. La séparation ne vaut la peine que si le plancher plus faible s’arrête là où l’appareil s’arrête.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Ce qu’un ancien certificat de fournisseur casse réellement

L’erreur de vérification est une liaison de rôle manquante : sans elle, le client acceptera tout certificat qui se chaîne à une AC de confiance, que ce certificat ait été émis pour un serveur ou non. Liez d’abord le certificat au rôle de serveur, et traitez la liaison comme une exigence et non comme un bouton de réglage. Seul un profil qui échoue encore après cette étape a un véritable problème de certificat.

Un ancien certificat de fournisseur dont la taille de clé ou l’algorithme de signature ne satisfait plus la politique par défaut d’OpenSSL est le cas d’un changement encadré du niveau de sécurité sur le canal de contrôle. Baisser le niveau à cet endroit ne désactive pas la vérification, et cela ne doit jamais être combiné avec une AC vide, un réglage de vérification désactivé ou un nom d’hôte non vérifié. Gardez la ligne à l’intérieur du seul profil qui en a besoin ; exporter globalement une configuration OpenSSL assouplie donnerait le même assouplissement à chaque programme de la machine.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Lisez les valeurs négociées, pas la bannière

Au niveau de verbosité 4, les deux extrémités impriment la version TLS et le chiffrement du canal de contrôle sur lesquels elles se sont accordées, ainsi que le chiffrement de données de la session. Lisez ces lignes plutôt que la bannière d’initialisation, qui signale un succès et non ses conditions. Reconnectez ensuite un client moderne au listener principal et confirmez qu’il atterrit toujours sur une suite moderne, car une exception qui a fui dans la configuration partagée se voit ici en premier. Les valeurs que vous copiez deviennent la base de référence pour la prochaine revue.

Testez l’ancien appareil seul : il devrait se connecter, et il devrait être la seule session des journaux à montrer les paramètres plus faibles. Si un second pair négocie aussi l’ancienne suite, l’exception est plus large que prévu et la séparation du listener n’a pas vraiment eu lieu. Notez les deux observations, pas seulement la conclusion.

Chaque exception a besoin d’un propriétaire et d’une date

Une exception sans condition de retrait devient discrètement la valeur par défaut, alors placez l’appareil, le propriétaire, la raison et la date à laquelle elle disparaît à côté de la configuration qu’elle justifie. Sans cette ligne, le plancher plus faible survit au matériel qui en avait besoin.

Remplacer le client, ou demander un profil à jour au fournisseur, est le résultat à viser ; l’exception est un délai et non une conception. Quand l’appareil est retiré, supprimez le listener et le profil dans le même changement afin qu’aucune moitié ne reste en marche. Rien de tout cela ne rend les anciens paramètres sûrs, cela empêche seulement la limite d’un appareil de devenir la base de tous.