Cloudflare a annoncé l’extension de son service Automatic SSL/TLS avec la fonctionnalité Automatic Key Exchange, qui apprend les capacités des serveurs d’origine des clients avant les connexions réelles, puis sélectionne l’algorithme d’échange de clés approprié dès la première tentative. La fonctionnalité privilégie l’algorithme hybride résistant à l’informatique quantique X25519MLKEM768 lorsque le serveur d’origine et le chemin réseau peuvent l’utiliser.
La fonctionnalité vise la seconde connexion établie par Cloudflare entre son infrastructure et le serveur d’origine, et non la connexion de l’utilisateur à la plateforme. Comme TLS 1.3 impose au client d’envoyer un algorithme d’échange de clés dans le premier message, Cloudflare devait utiliser une estimation fixe, X25519. Si le serveur préfère un autre algorithme, il envoie un HelloRetryRequest, ce qui relance la négociation et ajoute un cycle complet de latence réseau.
De l’estimation à la mesure
Cloudflare effectue une série de négociations TLS légères en dehors du chemin du trafic de production, en présentant à chaque test un algorithme parmi X25519, P-256, P-384, P-521 ou X25519MLKEM768. Les résultats servent à déterminer ce que prend en charge chaque origine, les sous-domaines étant évalués séparément et les résultats étant pondérés selon le volume réel de trafic de chacun.
La plateforme sélectionne ensuite la meilleure option disponible selon un ordre qui commence par l’algorithme hybride post-quantique, puis revient à l’algorithme classique le plus rapide accepté par l’origine. Cloudflare déploie progressivement la modification sur une petite partie du trafic de l’origine, surveille le taux d’échec et les demandes de HelloRetryRequest, puis rétablit la configuration si les performances dépassent la référence. Elle réexamine également les origines chaque jour afin de suivre les changements liés aux équilibreurs de charge, aux bibliothèques TLS ou aux configurations des serveurs.
Impact annoncé sur les performances et la sécurité
Cloudflare affirme que le taux de demandes de HelloRetryRequest sur les origines incluses dans la mesure est passé d’environ 52 % à 3,7 %, avec une réduction supérieure à 150 millisecondes du temps de négociation au 90e percentile. L’impact apparaît particulièrement dans les requêtes qui nécessitent une nouvelle connexion à l’origine, comme les requêtes dynamiques ou les cas d’absence de contenu dans le cache CDN ; les connexions existantes via keep-alive n’ont pas besoin d’une nouvelle négociation.
Selon l’entreprise, 99,2 % des connexions TLS 1.3 post-quantiques du groupe examiné s’achèvent désormais en un seul cycle. Le volume de trafic des origines utilisant un échange de clés post-quantique est également passé d’environ 25 milliards à 45 milliards de connexions par jour, tandis que des centaines de milliers de domaines ont obtenu cette protection sans intervention manuelle. Cloudflare indique que 33 % des plus d’un million de domaines du groupe initial se sont vu attribuer X25519MLKEM768, tandis que 64 % sont restés sur X25519 et que 3 % ont utilisé d’autres algorithmes classiques.
Qu’est-ce qui change concrètement pour les clients ?
La fonctionnalité est activée par défaut pour les domaines nouveaux et existants qui utilisent des origines prenant en charge TLS 1.3. Elle peut être contrôlée depuis le tableau de bord Cloudflare, dans SSL/TLS puis Origin connection & post-quantum encryption. Si l’origine ne prend pas en charge X25519MLKEM768, la fonctionnalité n’ajoutera pas cette capacité automatiquement, mais elle peut sélectionner un algorithme classique compatible et éviter une nouvelle négociation inutile.
Cloudflare propose également deux paramètres de conformité : limiter la négociation à l’échange hybride post-quantique ou la limiter aux algorithmes compatibles avec FIPS. Toutefois, l’activation de l’échange post-quantique sur une origine qui ne le prend pas en charge peut entraîner l’échec de toutes les connexions TLS 1.3 ; l’entreprise déconseille donc d’utiliser cette option sans vérification préalable. Cloudflare Radar propose un test de la capacité du serveur et du chemin réseau à gérer ces connexions, notamment les problèmes liés aux pare-feu, aux systèmes intermédiaires et aux messages fragmentés.
Pourquoi cette annonce est-elle importante ?
La modification combine une amélioration directe des performances et une tentative d’élargir l’adoption du chiffrement post-quantique sans demander aux opérateurs de sites de définir manuellement l’algorithme. Elle ne remplace toutefois pas la mise à niveau du serveur d’origine ou de l’équilibreur de charge ; la plateforme ne peut pas négocier un algorithme qui n’est pas pris en charge. De même, l’échange de clés post-quantique protège contre le scénario dans lequel des données chiffrées sont enregistrées puis déchiffrées ultérieurement, mais il ne résout pas à lui seul l’usurpation de l’identité de l’origine ni les risques d’abaissement du niveau d’authentification. Cloudflare indique que les prochaines étapes comprennent la vérification de la prise en charge des certificats ML-DSA et l’interdiction du retour aux certificats classiques lorsqu’une protection post-quantique stricte est disponible.