Version TLS non autorisée d’AnyConnect sous Linux : délimitez d’abord la portée de la correction
Une politique LEGACY à l’échelle de l’hôte, une configuration OpenSSL par processus et une VM jetable comparées, plus la modification de la passerelle qui supprime définitivement l’erreur.
Cette erreur arrive avant l’invite de mot de passe, et c’est la partie utile : rien n’a encore été authentifié, donc les identifiants ne sont pas le problème. Sous Linux, la même boîte de dialogue AnyConnect peut venir d’une ancienne version du protocole, d’un groupe d’échange de clés de 1024 bits ou d’une suite de chiffrement que la politique cryptographique du système refuse. Je l’ai éliminée de trois manières différentes sur trois machines, et ce qui distingue ces correctifs, c’est la portée, pas l’astuce. Chacun est défendable au bon endroit et un mauvais choix par défaut partout ailleurs.
Lisez le message avant de toucher à la politique
Conservez la chaîne exacte de la boîte de dialogue. Une plainte de version vise la couche protocole, une plainte de certificat vise la confiance ou le nommage, et un échec de connexion vise les identifiants. Une passerelle qui propose TLS 1.0 avec un groupe DHE de 1024 bits, AES-256-CBC et une signature SHA-1 peut avoir un certificat parfaitement valide et être malgré tout rejetée par une politique moderne avant même que vos identifiants soient envoyés.
Sondez le point de terminaison avec l’OpenSSL du système, en utilisant le vrai nom d’hôte et le port utilisé par le client.
L’échec de openssl s_client -connect vpn.example.com:443 -servername vpn.example.com alors que -tls1 -cipher DEFAULT@SECLEVEL=0 réussit indique que la limite tient à la fois à la version et à la taille de clé. Si la première commande signale une petite clé DH plutôt qu’une alerte de protocole, la version est correcte et seul le groupe demande attention. Ne mettez jamais de clé privée ni de mot de passe dans la sonde.
Option 1 : assouplir tout l’hôte avec la politique cryptographique
Sur Fedora et RHEL 8 et 9, update-crypto-policies --set LEGACY abaisse la politique système d’OpenSSL, et update-crypto-policies --show confirme ce qui est actif. Cela rétablit généralement le tunnel, mais la politique est lue au démarrage d’un processus : redémarrez donc le client et tout assistant qu’il a lancé avant de retester. Elle autorise aussi des protocoles plus anciens et des groupes plus faibles pour chaque client TLS de la machine, du navigateur de la fenêtre voisine au gestionnaire de paquets qui met à jour le noyau.
Cette étendue est tout l’intérêt et tout le problème. LEGACY s’applique à tout l’hôte, persiste et s’oublie facilement : il devrait être une étape de diagnostic ou une exception documentée sur une image gérée, jamais l’état de repos d’un poste de travail. J’en ai vu un rester en LEGACY pendant deux ans parce qu’un seul portail interne en avait besoin, et personne ne savait dire quand cela avait commencé.
Debian et Ubuntu n’ont pas d’interrupteur unique pour cela. L’équivalent est une modification de /etc/ssl/openssl.cnf qui fixe un MinProtocol plus bas et CipherString = DEFAULT@SECLEVEL=0 dans la section des valeurs par défaut du système. Même portée, fichier différent, un peu plus facile à perdre de vue lors d’une mise à niveau de version.
Option 2 : un fichier de configuration pour un seul client
Une configuration OpenSSL par processus garde la modification dans un seul arbre de processus, mais seulement si le fichier est câblé comme la bibliothèque l’attend. Nommer une section ssl_conf ne suffit pas : OpenSSL lit la clé de niveau supérieur openssl_conf, la suit jusqu’à une section d’initialisation, et n’atteint qu’ensuite les valeurs par défaut de SSL.
openssl_conf = openssl_init
[openssl_init]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0Pointez OPENSSL_CONF vers ce fichier et lancez le client VPN via un wrapper qui l’exporte. Tout le reste de l’hôte conserve la politique par défaut, et c’est la propriété qui compte quand la question de conformité arrive. Vérifiez que le fichier est réellement appliqué avant d’accuser la passerelle : OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 doit lister des chiffrements TLS 1.0, et un résultat vide signifie que la chaîne est rompue et que le client a silencieusement gardé les valeurs par défaut du système.
Le fichier est sensible à la version. OpenSSL 1.1.1 et 3.x acceptent les mêmes noms de section, mais le traitement des directives autour des fournisseurs a changé en 3.x : vérifiez donc avec le journal du client et une poignée de main de test au lieu de supposer que le fichier a été lu. Une faute de frappe dans le nom de section échoue en mode ouvert, et le client utilise discrètement les valeurs par défaut du système.
La limite, c’est la couverture. Tout ce qui est lié à GnuTLS ou NSS ignore OPENSSL_CONF, tout comme tout processus auxiliaire que le client lance sans hériter de l’environnement. Vérifiez avec ldd quelle bibliothèque TLS le binaire utilise réellement avant de construire le wrapper, car la réponse décide si cette option existe tout court.
Option 3 : une VM ou un conteneur jetable
Pour un prestataire qui frappe une passerelle ancienne pendant quinze jours, une VM dédiée avec la politique assouplie est une frontière plus propre que le poste de travail. L’ancienne surface et le profil de navigation quotidien cessent de partager une politique de noyau, et la mise au rebut est une suppression, pas une constatation d’audit.
Cela reste une machine en réseau : limitez donc son accès et tenez-la à l’écart de la navigation générale. Le coût de maintenance est une image de plus à corriger, ce qui est réel mais borné et visible, contrairement à un indicateur LEGACY oublié sur un portable.
Ce que la comparaison vous laisse
Choisissez sur trois questions : qui a besoin de l’ancien protocole, pour combien de temps, et qui remarquera si l’exception survit à sa raison. Une application, une personne, quelques jours, pointent vers la configuration par processus. Une flotte entière derrière un seul équipement pointe vers la passerelle elle-même. Tout ce qui exige une politique LEGACY permanente sur l’hôte est une décision d’achat déguisée en solution technique.
Le correctif durable appartient à l’équipement : TLS 1.2 ou ultérieur, un groupe d’au moins 2048 bits, un chiffrement AEAD et un certificat à signature moderne. Demandez ce changement au propriétaire de l’équipement, puis confirmez la version et le chiffrement négociés dans le journal du client. Notez l’exception avec l’hôte, la passerelle, le protocole négocié, l’approbateur et une date d’expiration, car c’est cette note qui empêche un contournement temporaire de devenir la valeur par défaut.