Cloudflare passe ses origines au post-quantique

Ce qui se passe

TLS 1.3 impose au client de choisir un algorithme d'échange de clés dans son tout premier paquet, avant que le serveur n'ait rien dit de lui. Bonne pioche : la poignée de main tient en un aller-retour. Mauvaise pioche : le serveur renvoie un HelloRetryRequest, on recommence, et la connexion en coûte deux.

Pendant des années, Cloudflare a envoyé la même supposition vers toutes les origines : X25519, supporté par plus de 95 % d'entre elles. Sûr — et sous-optimal pour environ 30 % des connexions, une fois mesurées.

Automatic Key Exchange remplace la supposition par une mesure, et il est actif par défaut sur les domaines existants comme sur les nouveaux.

Comment ça marche

1. Pour chaque origine parlant TLS 1.3, Cloudflare lance quelques poignées de main légères ne proposant qu'un seul groupe à la fois : X25519, P-256, P-384, P-521 ou X25519MLKEM768. Le sondage se fait hors du chemin du trafic de production.
2. Chaque sous-domaine est évalué séparément, puis pondéré par son volume de trafic réel — un sous-domaine dormant ne pèse pas autant que www ou api.
3. Parmi les groupes supportés, l'hybride post-quantique X25519MLKEM768 est choisi en priorité, sinon la courbe classique la plus rapide acceptée.
4. La nouvelle préférence part sur une petite part du trafic, sous surveillance du taux d'échec et de reprise ; si les reprises dépassent la ligne de base, elle est annulée. Le pire cas est un aller-retour supplémentaire, pas une connexion cassée.
5. Les origines sont rescannées chaque jour : une bibliothèque TLS qui gagne le post-quantique dans une mise à jour de routine est détectée au scan suivant.

Les chiffres

Sur la première cohorte de plus d'un million de domaines : 64 % restent sur X25519 et ne voient rien changer, 33 % basculent sur X25519MLKEM768, 3 % adoptent une autre courbe classique préférée par leur origine. Environ 9 000 domaines par jour changent de préférence.

Pourquoi ne pas avoir mené avec le post-quantique dès le départ ? Un keyshare X25519MLKEM768 pèse 1 216 octets contre 32 pour X25519, ce qui pousse le ClientHello au-delà d'un seul paquet réseau — et environ 0,34 % des origines scannées échouaient alors à terminer la poignée de main. Le support post-quantique côté origines est passé de 0,5 % en 2023 à 12,8 % aujourd'hui.

Le piège à connaître

Un nouveau réglage Compliance requirements permet de restreindre les algorithmes négociés, avec deux options : Post-quantum hybrid et FIPS. La première supprime entièrement les algorithmes classiques.

Cloudflare le dit sans détour : imposer l'hybride post-quantique à une origine qui ne parle pas X25519MLKEM768 ne laisse aucun algorithme commun, et toutes les connexions TLS 1.3 échouent. Sauf obligation de conformité stricte, laissez les deux cases décochées. Le réglage se trouve dans le tableau de bord, sous SSL/TLS > Overview > Configure.

Ce que ça change pour vous

Si votre origine parle déjà TLS 1.3, il n'y a rien à faire : la meilleure option disponible sera choisie, post-quantique quand c'est possible, meilleure courbe classique sinon. Si vous voulez le post-quantique et que votre pile ne le supporte pas, deux voies : passer par un tunnel Cloudflare, dont la connexion utilise déjà un échange post-quantique, ou mettre à jour votre terminaison TLS — les versions récentes d'OpenSSL, BoringSSL et rustls proposent X25519MLKEM768, mais une liste de courbes configurée à la main il y a des années écrasera ce défaut.

Un audit complet est nécessaire : répartiteurs de charge, WAF, boîtiers d'inspection — tout ce qui termine ou inspecte TLS entre votre serveur et Cloudflare.

À retenir

L'enjeu n'est pas la milliseconde, c'est harvest now, decrypt later : du trafic chiffré enregistré aujourd'hui pour être lu le jour où un calculateur quantique le permettra. Cloudflare vise un Internet quantiquement sûr en 2029, et le seul moyen d'y arriver est que personne n'ait à le configurer.

Source : Automatic Key Exchange: faster, post-quantum secure origin handshakes