SECLEVEL=0 soigne le symptôme, pas le certificat

Une connexion OpenVPN échoue, quelqu'un trouve un correctif d'une ligne qui ajoute SECLEVEL=0, et le tunnel monte. Ce qui a changé n'est ni le certificat ni la suite de chiffrement ; un seuil d'acceptation à l'échelle de la bibliothèque s'est déplacé, et tout ce que le processus fait ensuite hérite de la nouvelle frontière. Cela vaut la peine d'être compris avant que la même ligne soit copiée dans chaque profil du parc.

Déterminez quelle bibliothèque et quelle politique sont en vigueur

SECLEVEL est un concept d'OpenSSL, donc la première question est de savoir si votre build utilise OpenSSL. OpenVPN peut être lié à plus d'une bibliothèque cryptographique, et un réglage qui s'applique à l'une d'elles n'a aucun sens pour les autres. Demandez au binaire avec quoi il a été construit, puis demandez à la bibliothèque quelle version et quelle configuration elle a chargées:

openvpn --version | head -3
openssl version -a

Lisez la sortie de version attentivement, car les distributions modifient les valeurs par défaut. Certaines livrent une configuration système qui élève le niveau minimal au-dessus de la valeur par défaut d'amont, et c'est pourquoi le même profil se comporte différemment sur deux machines avec des paquets OpenVPN identiques. La politique effective est celle chargée par le processus en cours, pas celle du manuel d'amont.

Séparez ensuite les deux couches que les gens confondent. OpenVPN a ses propres contrôles TLS, dont un réglage de profil de certificat et des listes de chiffrement explicites, et ceux-ci se situent au-dessus de ce que la bibliothèque impose. Abaisser le niveau de la bibliothèque ne change pas les chiffrements que votre configuration OpenVPN énumère, et restreindre la liste OpenVPN n'élève pas le seuil de la bibliothèque. Savoir quelle couche vous a refusé est ce qui empêche le correctif de rester une supposition.

Séparez les trois choses qui peuvent être rejetées

Le premier candidat est le matériel d'identité : un certificat dont la clé est trop petite ou dont l'algorithme de signature n'est plus accepté par la politique. Le deuxième est un paramètre d'échange de clés, comme un groupe que la politique juge trop faible. Le troisième est une suite de chiffrement que la politique exclut. Les trois peuvent produire un échec de handshake, et seuls le texte de l'erreur et l'étape de négociation les distinguent.

Aucun de ces trois n'est le chiffrement du canal de données. OpenVPN négocie le chiffrement de son tunnel séparément du handshake TLS, donc une connexion qui réussit après un changement de niveau de sécurité ne dit rien sur le chiffrement qui protège vos données. Si la question que vous posez réellement porte sur la confidentialité des données, vous regardez le mauvais bouton.

Abaisser le niveau élargit l'acceptation des trois entrées à la fois. C'est la partie que les gens manquent : le correctif qui admet un vieux certificat admet aussi un groupe faible et une suite que vous n'aviez peut-être pas l'intention d'autoriser. Une seule erreur a motivé le changement, et le changement est plus large que l'erreur. Cette asymétrie est la raison pour laquelle une exception ciblée vaut mieux qu'une valeur par défaut pour tout le parc.

Changez l'entrée, pas le seuil

Conservez l'erreur exacte avant de toucher à la configuration, y compris l'étape qui l'a signalée et l'objet qu'elle a nommé. Un problème de certificat se règle en remplaçant le certificat par quelque chose que la politique actuelle accepte, ce qui signifie généralement le réémettre auprès de l'autorité plutôt que réinstaller le même fichier.

Si l'entrée rejetée appartient à un pair que vous ne contrôlez pas, la conversation se fait avec son propriétaire au sujet du matériel de remplacement pris en charge. Abaisser votre propre seuil pour accommoder un système que personne ne maintient reporte le coût de ce pair vers tous ceux qui se connectent après lui.

Là où le serveur applique la politique, vérifiez si un réglage au niveau d'OpenVPN est la cause réelle avant de blâmer la bibliothèque. Un profil de certificat qui exige une classe plus stricte que celle que le certificat déployé peut satisfaire échouera quel que soit le niveau de sécurité, et supprimer ce profil est un changement plus étroit que désactiver les contrôles de la bibliothèque.

Si vous devez l'abaisser, limitez-le et documentez-le

Parfois, une exception de compatibilité approuvée est la bonne réponse, en particulier pour un pair hérité avec un plan de retrait daté. Limitez-la au service qui en a besoin plutôt qu'à tout l'hôte : un fichier de configuration par service ou une configuration OpenSSL dédiée a un rayon d'action plus petit qu'une exportation dans le profil global.

Notez quatre choses avec l'exception : le réglage exact, le propriétaire qui l'a approuvée, les clients concernés et la condition à laquelle elle sera retirée. Une exception sans condition de retrait est un affaiblissement permanent assorti d'une justification temporaire.

Le retour arrière doit être une seule étape que vous avez déjà testée. Conservez la configuration précédente, appliquez le changement, confirmez que le service démarre et sachez exactement quel fichier restaurer si la prochaine connexion se comporte différemment de ce qui était prévu.

Vérifiez l'identité et la protection ensuite

Une connexion réussie prouve seulement que les conditions révisées l'ont admise. Confirmez que la vérification du nom d'hôte et du pair fait toujours son travail, que le certificat utilisé est celui que vous comptiez déployer et que le canal de données négocié correspond à la politique que vous croyez avoir.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

La référence des niveaux de sécurité d'OpenSSL précise que le cadre applique des limites aux clés, signatures, groupes et suites ensemble, et que le niveau zéro autorise tout ce que le rappel vérifie. C'est la portée de ce que vous avez changé, et c'est la phrase à citer quand on vous demande si le correctif était étroit.

La passation qui résiste à un audit indique quelle politique a rejeté quelle entrée, ce qui a été modifié et ce qui reste accepté en conséquence. « Cela fonctionne avec SECLEVEL=0 » est une observation sur une connexion, pas une évaluation de sécurité du déploiement.