Vérifier qu'une connexion TLS a réellement négocié X25519MLKEM768

Objectif

État au 25 octobre 2026. Établir le groupe d'échange de clés sélectionné par une connexion TLS donnée. Vérifier de nouveau les groupes par défaut de la bibliothèque déployée, les politiques du navigateur et la configuration de terminaison TLS après les mises à niveau. X25519MLKEM768 combine le mécanisme classique X25519 avec ML-KEM ; sa présence dans une configuration indique une capacité, pas le résultat d'une connexion.

Prérequis

Utiliser un point de terminaison dont on assure l'administration, son nom d'hôte DNS et son magasin habituel de certificats de confiance. La documentation d'OpenSSL 3.5 indique la prise en charge de ML-KEM et l'utilisation par défaut d'une part de clé hybride. Le rapport de Chromium pour le quatrième trimestre 2024 indique que ML-KEM est activé par défaut à partir de Chrome 131 sur les plateformes citées. Les deux extrémités doivent prendre en charge un groupe commun ; des paramètres explicites peuvent modifier le résultat. Ces versions sont des repères fonctionnels, pas des recommandations d'installation d'anciennes versions.

Étapes

1. Consigner la version de compilation du client, la destination, l'heure et le chemin réseau. Vérifier si la connexion se termine sur une application, un proxy inverse ou une passerelle d'inspection. Traiter chaque segment ayant sa propre terminaison comme une entrée d'inventaire distincte.

2. Dans Chrome DevTools, ouvrir le panneau Confidentialité et sécurité et sélectionner l'origine concernée sous Sécurité. Examiner les détails de sa connexion et consigner le groupe d'échange de clés s'il est affiché. La vue du certificat ou un indicateur générique de connexion sécurisée ne suffit pas. La documentation citée pour ce panneau a été mise à jour pour la dernière fois le 27 février 2025 ; les libellés peuvent changer d'une version de compilation à l'autre.

3. Avec une version appropriée d'OpenSSL, établir une nouvelle connexion dans un terminal interactif en utilisant ses paramètres par défaut. Remplacer le nom d'hôte d'exemple partout où il apparaît :

   openssl s_client -connect service.example:443 -servername service.example \
     -tls1_3 -verify_hostname service.example -verify_return_error -brief
   

   Attendre le résumé de la négociation, consigner le groupe négocié et le résultat de la vérification du certificat, puis arrêter le test avec Ctrl-C. Répéter avec -groups X25519MLKEM768. Une réussite avec ce seul groupe établit sa prise en charge sur le chemin testé. Elle n'établit pas ce que sélectionnent les clients ordinaires. Fournir le fichier d'autorités de certification approprié pour un domaine de confiance privé ; conserver la vérification du nom d'hôte.

4. Consulter curl --version pour identifier son moteur TLS. Pour une version utilisant OpenSSL et prenant en charge le groupe, comparer une requête ordinaire avec :

   curl --verbose --tlsv1.3 --tls-max 1.3 --curves X25519MLKEM768 \
     --output /dev/null https://service.example/
   

   Le paramétrage explicite du groupe dans curl remplace la liste par défaut du moteur. Conserver les contrôles de certificat et examiner le résultat de la négociation ; un échec seul ne permet pas de distinguer un groupe non pris en charge d'un problème de connexion sans rapport. Ne pas supposer que tous les moteurs affichent les mêmes champs de diagnostic.

5. Faire correspondre la connexion aux données de télémétrie du serveur. Lorsque c'est possible, journaliser le groupe sélectionné plutôt que la liste configurée ou proposée. OpenSSL expose SSL_get_negotiated_group() à cet effet. Si le serveur ne fournit pas cette télémétrie, consigner cette lacune au lieu de considérer les noms des suites cryptographiques comme une preuve du groupe utilisé.

Résultat attendu

Le relevé distingue la sélection par défaut, la prise en charge d'un groupe imposé et les chemins non vérifiés. Consigner séparément les constats sur l'authentification par certificat et sur l'échange de clés. Réexécuter les deux contrôles après la modification d'une restriction de groupes ou la mise à niveau d'un composant assurant la terminaison TLS.

Limites et base de vérification

Cette procédure repose sur la documentation ; aucune mesure sur un point de terminaison n'est revendiquée. Une connexion de navigateur et un test TCP en ligne de commande peuvent emprunter des chemins différents. La réutilisation de session peut aussi empêcher l'observation d'un nouvel échange. OpenSSL indique que les parts de clés hybrides plus volumineuses peuvent révéler des dysfonctionnements d'équipements intermédiaires. Diagnostiquer ces échecs avant d'accepter une exception permanente limitée aux mécanismes classiques.