Pour ce qui compte le plus aujourd'hui, un site web est prêt pour le post-quantique lorsque son serveur peut établir les clés de session au moyen d'un échange de clés post-quantique hybride. L'option la plus déployée est X25519MLKEM768, qui combine le X25519 classique avec ML-KEM-768, le mécanisme d'encapsulation de clés normalisé par le NIST dans FIPS 203. Il est enregistré par l'IANA comme groupe TLS 0x11EC et c'est le seul groupe post-quantique que l'IANA marque comme recommandé.
Pourquoi commencer par l'échange de clés ? À cause de l'attaque « collecter maintenant, déchiffrer plus tard » : un attaquant peut enregistrer aujourd'hui du trafic chiffré et le déchiffrer dès qu'un ordinateur quantique de grande taille existera. Seul l'échange de clés protège le trafic enregistré. Les certificats et les signatures comptent aussi, mais une signature doit être falsifiée en temps réel : leur migration peut donc venir plus tard.
Méthode 1 : un test en ligne
Le plus rapide consiste à saisir le domaine dans le scanner PQC Status. Il propose au serveur chaque groupe post-quantique normalisé, un par un, et indique lesquels sont acceptés, quel groupe obtient réellement un navigateur récent, les versions TLS, les suites cryptographiques et la chaîne de certificats. Cela prend quelques secondes et ne nécessite aucun accès au serveur.
Méthode 2 : une commande OpenSSL
Avec OpenSSL 3.5 ou ultérieur (vérifiez avec openssl version), proposez uniquement le groupe hybride. Si le serveur le prend en charge, la négociation réussit ; sinon, elle échoue :
openssl s_client -connect example.com:443 -servername example.com \
-groups X25519MLKEM768 -brief </dev/nullUn serveur prêt pour le post-quantique répond par une ligne telle que :
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768Un serveur qui ne prend en charge que des groupes classiques interrompt la négociation par une alerte, généralement ssl/tls alert handshake failure (alerte numéro 40). Notez que s_client se termine avec le code 0 dans les deux cas : lisez la sortie, pas le code de retour.
Pour tester les autres groupes hybrides, remplacez le nom du groupe par SecP256r1MLKEM768 ou SecP384r1MLKEM1024. Ce dernier correspond au niveau 5, que l'ANSSI privilégie lorsque c'est possible.
Méthode 3 : le navigateur
Les versions actuelles de Chrome, Edge et Firefox proposent X25519MLKEM768 par défaut. Dans les navigateurs basés sur Chromium, ouvrez les outils de développement, allez dans le panneau Sécurité et consultez les détails de la connexion : la ligne consacrée à l'échange de clés indique le groupe négocié. Vous voyez ainsi ce qu'a obtenu votre propre navigateur, ce qui suffit pour une vérification rapide mais dépend de la version du navigateur.
Bien interpréter le résultat
Un CDN peut masquer votre origine
Si votre site est derrière Cloudflare, Fastly, CloudFront ou un autre CDN, tout test externe voit la périphérie, pas votre serveur. De nombreux CDN activent par défaut l'échange de clés hybride en périphérie : le site paraît donc prêt. La connexion entre le CDN et votre serveur d'origine est un lien TLS distinct qui peut n'utiliser encore qu'un échange de clés classique. Testez directement l'origine, depuis une machine autorisée à la joindre, avec la commande OpenSSL ci-dessus.
TLS 1.3 est un prérequis
L'échange de clés hybride n'existe qu'en TLS 1.3. Un serveur limité à TLS 1.2 ne peut pas être prêt pour le post-quantique, quel que soit son certificat. Le mémorandum M-26-15 de l'OMB américain impose par ailleurs TLS 1.3 aux systèmes fédéraux d'ici janvier 2030.
Les certificats classiques sont normaux aujourd'hui
Votre certificat utilise presque certainement RSA ou ECDSA. C'est attendu : les autorités de certification publiques ne délivrent pas encore de certificats post-quantiques pour le web. Consignez l'algorithme du certificat dans votre inventaire, mais ne le considérez pas comme un obstacle à l'étape de l'échange de clés.
Les anciens projets Kyber ne comptent pas
Certains déploiements précoces utilisaient X25519Kyber768Draft00, une version de l'algorithme antérieure à la norme. Elle est obsolète : les serveurs devraient passer aux groupes ML-KEM normalisés.
Que faire si la réponse est non
- Vérifiez la bibliothèque TLS : OpenSSL 3.5 ou ultérieur, ou une bibliothèque équivalente prenant en charge ML-KEM.
- Activez le groupe hybride sur votre serveur web ou votre répartiteur de charge, en conservant X25519 comme solution de repli. Notre guide pour activer ML-KEM sur nginx, Apache, HAProxy et Caddy donne les directives exactes.
- Relancez le test, puis ajoutez le résultat daté à votre inventaire cryptographique.