Le premier pas post-quantique que votre CDN ne fait pas à votre place

Un ingénieur qui ouvre la page d'état post-quantique de Cloudflare y lit de bonnes nouvelles depuis trois ans sans avoir rien fait. Sur le segment entre le navigateur d'un visiteur et la bordure de Cloudflare, le chiffrement post-quantique est actif par défaut depuis 2023, avec l'accord de clés hybride que l'on écrit aujourd'hui X25519MLKEM768, et aucun client ne l'a configuré. Il est arrivé comme arrive la météo.

Le 29 juillet, cette manière de travailler s'est arrêtée. Cloudflare a annoncé l'authentification post-quantique sur l'autre segment, entre son réseau et les serveurs d'origine exploités par ses clients, avec des signatures ML-DSA. L'authentification n'est pas une chose qu'un proxy peut assurer à votre place, car ce qui est attesté, c'est votre serveur. Pour en profiter, ce serveur doit détenir et présenter un certificat signé avec un algorithme qu'il n'a sans doute jamais vu.

Ce qui a réellement été livré

Deux produits portent le changement. Authenticated Origin Pulls est le mécanisme par lequel Cloudflare présente un certificat client à votre origine, afin que celle-ci puisse refuser les connexions qui ne sont pas passées par Cloudflare, et il accepte désormais ML-DSA aux niveaux de configuration par zone et par nom d'hôte. Le niveau global est annoncé pour plus tard. Le Custom Origin Trust Store, qui permet à un client de téléverser ses propres autorités de certification plutôt que de s'en remettre à l'ensemble public, accueille maintenant des autorités signant en ML-DSA, de sorte qu'un certificat d'origine puisse être validé face à un signataire post-quantique.

Les trois jeux de paramètres de FIPS 204 sont pris en charge : ML-DSA-44, ML-DSA-65 et ML-DSA-87. L'accord de clés de la connexion demeure l'hybride X25519MLKEM768. Autrement dit, la confidentialité de ce segment était déjà réglée ; ce qui change, c'est la partie qui prouve qui se tient à chaque bout.

Cinq choses à modifier sur une machine qui vous appartient

La liste des prérequis est courte et chaque point tombe de votre côté de la connexion. Il faut OpenSSL 3.5.0 ou plus récent sur l'origine, ne serait-ce que pour produire une chaîne de certificats ML-DSA. Le certificat doit être téléversé dans l'encodage à graine seule que définit FIPS 204, qui n'est pas celui que la plupart des outils produisent par habitude. Le serveur web de l'origine, NGINX dans l'exemple donné par Cloudflare, doit être configuré soit pour présenter le certificat ML-DSA, soit pour vérifier le certificat client face à lui. Si vous utilisez le Custom Origin Trust Store, le mode SSL/TLS de la zone doit être Full (strict). Enfin, la confiance dans le mécanisme vulnérable au quantique doit être retirée ensuite, car la laisser en place permet à un attaquant de négocier l'ancien chemin et rend le nouveau purement décoratif.

Rien de tout cela n'est exotique. OpenSSL 3.5.0 est sorti le 8 avril 2025 en version à support étendu, avec des mises à jour jusqu'en avril 2030, et c'est la première mouture à embarquer nativement les trois standards post-quantiques du NIST. La difficulté ne tient pas au numéro de version. Elle tient à ce que l'origine est souvent la machine la moins fréquentée de tout le parc : un boîtier, une machine confiée à un prestataire, une machine virtuelle que personne n'a reconstruite depuis sa mise en service, ou un répartiteur de charge dont la pile TLS reste le problème d'un autre jusqu'au jour où elle ne l'est plus.

Le déploiement de Cloudflare lui-même plaide pour une étape de recette. Le 10 juin 2026, l'entreprise a connu un incident de production au cours de cette mise en œuvre, provoqué par le contrôle du champ KeyUsage dans les certificats. C'est un détail d'extension de certificat, et il a frappé une équipe dont le métier est de construire des bibliothèques TLS, sur une infrastructure qu'elle maîtrise de bout en bout. Une entreprise de taille moyenne qui effectue la même modification un jeudi après-midi devrait s'attendre à rencontrer quelque chose de comparable.

Pourquoi le jeu recommandé est le plus petit

Cloudflare recommande ML-DSA-44 pour la plupart des usages et le décrit comme l'option la plus performante. Le choix technique se défend, et c'est aussi le plus petit des trois jeux de FIPS 204, situé en catégorie de sécurité 2 du NIST. Ailleurs, la recommandation par défaut la plus répandue est ML-DSA-65, catégorie 3. Les signatures post-quantiques sont volumineuses au regard de celles qu'elles remplacent et, sur un segment qui transporte chacune des requêtes entre bordure et origine, l'écart de taille représente un coût réel de latence et de bande passante, non un coût théorique.

Pour un dirigeant, l'important est qu'une décision porte désormais votre nom. Si votre politique de sécurité ou votre auditeur ont déjà retenu la catégorie 3 pour la signature, reprendre en silence la recommandation du CDN crée une dérogation qu'il faudra justifier. Consignez le jeu de paramètres et le motif par écrit, avant qu'un tiers ne découvre l'écart lors d'une revue.

L'échéance qui est réelle et celle qui ne l'est pas

Soyez clair sur l'urgence, car les deux moitiés du post-quantique avancent vraiment sur des horloges différentes. Le trafic chiffré enregistré aujourd'hui pourra être déchiffré par une machine future, et c'est ce qui fait de l'accord de clés un problème au présent. Une signature ne se falsifie pas à rebours de la même façon : personne ne mobilisera un calculateur quantique en 2032 pour fabriquer après coup une poignée de main survenue ce matin. La raison de commencer maintenant n'est pas que vous soyez attaqué, c'est la longueur de la file derrière ce changement, qui traverse les autorités de certification, le matériel, les boîtiers de prestataires et toutes les origines que vous aviez oubliées.

Cloudflare a daté sa propre file : sécurité post-quantique complète sur ses produits d'ici 2029, et un premier déploiement des Merkle Tree Certificates côté visiteur visé pour 2027. Ce sont ses échéances, pas les vôtres. La vôtre, c'est le prochain audit qui demandera ce qui protège la liaison entre votre CDN et vos serveurs, et en France c'est l'ANSSI qui donne la référence. La réponse honnête, aujourd'hui et pour presque tout le monde, tient en une phrase : de la cryptographie classique, avec un remplaçant disponible et inutilisé.