Cloudflare automatise le TLS post-quantique, avec un piège de compatibilité

Cloudflare a annoncé le 8 septembre 2026 le déploiement en cours d’Automatic Key Exchange, activé pour les zones existantes et par défaut pour les nouvelles. Dans son bilan du déploiement, l’entreprise indique que 99,2 % des connexions TLS 1.3 post-quantiques du groupe d’origines déjà analysé aboutissent désormais en un seul aller-retour.
Le mécanisme choisit automatiquement la première part de clé envoyée par Cloudflare à un serveur d’origine compatible. Il exige TLS 1.3, exclut les origines jointes par Cloudflare Tunnel et ne rend pas un serveur compatible par lui-même : d’après les conditions de configuration de Cloudflare, imposer exclusivement le mode hybride à une origine qui ne le prend pas en charge peut laisser les deux extrémités sans groupe d’échange commun.
Un ClientHello ciblé supprime une nouvelle tentative

Automatic Key Exchange intervient uniquement sur la connexion entre le réseau Cloudflare et le serveur d’origine. La liaison entre le visiteur et Cloudflare possède son propre handshake, ses propres clés et des réglages distincts.
Pour ouvrir une connexion TLS 1.3 vers l’origine, Cloudflare agit comme client et envoie un ClientHello avec les groupes d’échange pris en charge et une première part de clé. Auparavant, cette première proposition était statiquement fondée sur X25519. Une origine préférant un autre groupe pouvait répondre par un HelloRetryRequest, obligeant Cloudflare à produire la part demandée et à transmettre un deuxième ClientHello.
- Avant : ClientHello avec la part X25519, HelloRetryRequest de l’origine, second ClientHello, puis établissement de la connexion.
- Après : capacités mesurées en amont, part de clé préférée envoyée dès le premier ClientHello, puis établissement direct si l’origine l’accepte.
Sur le groupe d’origines mesuré par Cloudflare, le taux global de HelloRetryRequest est passé d’environ 52 % à 3,7 %, avec une réduction de plus de 150 ms de la latence du handshake au 90e percentile. Le bénéfice ne concerne que les nouvelles connexions : une requête passant par une connexion persistante déjà ouverte ne déclenche pas un nouvel échange de clés.
L’automatisation dépend de l’origine et du mode TLS

La zone doit utiliser Full, Full (strict) ou Strict (SSL-Only Origin Pull), et l’origine doit négocier TLS 1.3. La fonction est disponible sur tous les forfaits, mais Cloudflare Tunnel suit un autre chemin : la connexion post-quantique entre cloudflared et le réseau Cloudflare n’est pas pilotée par ce réglage.
Cloudflare sonde les origines actives hors du trafic de production, approximativement toutes les 24 heures. Le système vérifie séparément les groupes acceptés, choisit X25519MLKEM768 lorsque le chemin observé le permet et conserve sinon un groupe classique compatible. La préférence est ensuite déployée par étapes, avec surveillance des échecs de connexion et des HelloRetryRequest, puis retour au réglage précédent si les résultats se dégradent.
Une zone possédant plusieurs origines reçoit une préférence commune, calculée à partir de résultats pondérés par le trafic. Des backends utilisant des bibliothèques TLS ou des équipements intermédiaires différents peuvent donc compliquer la décision : la compatibilité du serveur le plus visible ne prouve pas celle de toutes les terminaisons.
X25519MLKEM768 protège par une construction hybride
X25519MLKEM768 combine l’échange classique X25519 avec ML-KEM-768. Le RFC 10024 de l’IETF, publié en août 2026, définit ce groupe parmi trois mécanismes hybrides pour TLS 1.3 et combine les secrets des deux composantes afin de préserver la sécurité tant qu’au moins l’une reste sûre.
Cette combinaison produit une part de clé cliente nettement plus volumineuse que celle de X25519 seul. Un serveur ancien, un répartiteur de charge, un pare-feu ou un autre équipement intermédiaire peut mal gérer un ClientHello réparti sur plusieurs segments. La sonde ne vérifie donc pas seulement une option déclarée par la bibliothèque TLS : elle teste la capacité observable du chemin jusqu’à l’origine avant que le trafic de production n’en dépende.
Dans la cohorte décrite par Cloudflare, environ 64 % des domaines analysés ont conservé X25519 comme préférence, 33 % sont passés à X25519MLKEM768 et 3 % à une autre courbe classique. Ces proportions décrivent le périmètre déjà scanné, pas l’ensemble des domaines utilisant Cloudflare ni un taux universel de compatibilité post-quantique.
Le danger vient de l’exigence stricte, pas du mode automatique

Deux commandes distinctes apparaissent dans la configuration. Automatic Key Exchange autorise la détection des capacités et réordonne les groupes compatibles. Les exigences de conformité filtrent au contraire les groupes que Cloudflare est autorisé à proposer, même si l’automatisation est désactivée.
Sans exigence réglementaire particulière, laisser les options de conformité décochées conserve un repli classique : X25519MLKEM768 est préféré lorsqu’il fonctionne, mais un autre groupe peut rester négociable. L’option « Post-quantum hybrid » retire les groupes classiques. Si une origine active ne prend pas en charge X25519MLKEM768, les nouvelles connexions TLS 1.3 vers celle-ci échouent faute de choix commun.
La décision peut ainsi être ramenée à trois contrôles :
- confirmer que la zone utilise un mode admissible et que chaque origine négocie TLS 1.3 ;
- tester X25519MLKEM768 sur toutes les terminaisons TLS et à travers les équipements intermédiaires ;
- ne rendre le mode hybride obligatoire qu’après avoir établi cette compatibilité sur l’ensemble des origines actives.
Le déploiement d’Automatic Key Exchange reste en cours, tandis que son activation est déjà la valeur par défaut. Le réglage automatique privilégie la compatibilité observée ; la garantie que toutes les connexions sont hybrides exige, elle, une infrastructure entièrement compatible et vérifiée.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.