Au-delà de l’inflation post-quantique : stratégies d’ingénierie pour maîtriser les handshakes TLS

Dans mon article précédent, nous avons étudié l’impact de l’établissement de clés post-quantique sur les performances. La réponse courte ? L’utilisation du CPU change peu, mais la taille du handshake TLS augmente sensiblement. Passer du X25519 classique au X25519MLKEM768 hybride ajoute environ 1,2 Ko au handshake TLS dans le sens critique. Lorsque nous ajouterons inévitablement des signatures post-quantiques (comme ML-DSA), les chaînes de certificats dépasseront facilement la fenêtre de congestion initiale de TCP (14,5 Ko), ce qui imposera des allers-retours supplémentaires (RTT) et introduira une véritable latence réseau.

La PKI du Web s’oriente déjà vers les Merkle Tree Certificates (MTC), conçus principalement pour résoudre ce problème de signatures post-quantiques très longues. Cependant, tous les systèmes ne pourront pas utiliser les MTC. Dans cet article, j’ai donc voulu explorer ce que nous pouvons faire d’autre. Et il y a en réalité pas mal de choses.

Nous disposons de deux leviers d’ingénierie principaux : l’un consiste à réduire la taille physique du handshake TLS, l’autre à réduire la fréquence des handshakes complets dès le départ.

Voici un tour d’horizon pratique de la manière d’optimiser les deux, et de l’état de la standardisation de ces solutions dans le secteur. Le meilleur ? Vous profiterez de ces optimisations dès aujourd’hui, même avec la cryptographie traditionnelle (RSA et/ou courbes elliptiques).

En ce qui concerne le handshake TLS, plusieurs options s’offrent à nous :

• Retirer les certificats racines des chaînes : L’une des erreurs de configuration les plus courantes consiste à transmettre le certificat de l’autorité racine avec les certificats intermédiaires. Les clients stockent déjà les racines de confiance localement ; les envoyer sur le réseau ne sert strictement à rien et gaspille une bande passante précieuse.
• Déployer la compression des certificats (RFC 8879) : La RFC 8879 permet aux points de terminaison de négocier des algorithmes de compression standard (Brotli, zlib ou zstd) pour les données de certificats. En pratique, cela compresse les chaînes de certificats volumineuses de 30 % à 50 %. Bien que la prise en charge soit fragmentée dans les navigateurs modernes (Chrome prend en charge Brotli ; Firefox prend en charge Brotli, zlib et zstd ; Safari prend en charge zlib), OpenSSL prend en charge les trois, si bien que cette technique devrait permettre quelques économies. Malheureusement, la compression ne fonctionne que sur le texte contenu dans les certificats. Par conception, les signatures et les clés publiques se compressent mal.
• Moderniser les clés publiques (ECC plutôt que RSA) : Si vous n’avez pas encore abandonné les anciens certificats RSA, faites-le. Passer de RSA-2048 à ECDSA réduit immédiatement la taille des clés publiques et des signatures, et donc celle des certificats, avant même l’arrivée de la PQC.
• Clés publiques brutes (RFC 7250) : Pour les communications de machine à machine, les API ou les environnements contraints dans lesquels les points de terminaison font déjà confiance à la clé publique du serveur ou la mettent en cache par un canal séparé, la RFC 7250 permet de se passer entièrement de la transmission des autorités intermédiaires et des enveloppes de certificats.

L’IETF a exploré plusieurs autres mécanismes de compression et de réduction, avec des niveaux d’adoption très variables :

• TLS Cached Info (RFC 7924) : Conçu pour permettre aux clients de signaler les certificats en cache afin d’éviter leur retransmission. Cette RFC a été publiée en mai 2026, mais elle n’est pas encore largement prise en charge par les bibliothèques et les agents utilisateurs. Elle sera peut-être mieux prise en charge lorsque nous commencerons à migrer vers la cryptographie post-quantique.
• Abridged Compression for WebPKI Certificates (draft-ietf-tls-cert-abridge) : Utilise des dictionnaires statiques pré-distribués pour compresser les structures des certificats. Bien qu’adopté par le groupe de travail TLS, ce brouillon a depuis expiré et semble abandonné.

TLS comporte deux types de handshakes : complets et abrégés (reprise de session). Ces derniers ne transportent aucun certificat, ce qui représente une économie considérable :

• Reprise de session : La reprise de session permet aux clients qui reviennent de s’authentifier à l’aide d’une clé symétrique pré-partagée, en évitant entièrement le lourd échange de clés asymétriques et le transfert des certificats.
• TLS 1.3 0-RTT (Early Data) : Pour les visiteurs récurrents, le 0-RTT permet aux données applicatives de circuler dès le tout premier envoi de paquets, avec le handshake de reprise, ce qui supprime totalement les délais d’aller-retour du handshake. Cette technique n’offre pas une confidentialité persistante (forward secrecy) complète et ne doit être utilisée que lorsque le premier envoi de l’agent utilisateur ne contient pas d’informations sensibles.

Le handshake le plus rapide est celui que vous n’avez jamais à effectuer. Éliminer les échanges asymétriques permet d’éviter la pénalité de taille croissante des clés post-quantiques.

• Ajuster les keep-alives : Ne laissez pas les connexions TCP ou TLS inactives se fermer prématurément. Allonger les délais de keep-alive au niveau applicatif et TCP sur les proxys de périphérie (par exemple NGINX, HAProxy, Envoy) permet de garder les sockets actifs pour un trafic client par rafales ou séquentiel.
• Déployer HTTP/2 et HTTP/3 (QUIC) : En multiplexant plusieurs requêtes HTTP sur une seule connexion sous-jacente, les protocoles modernes éliminent l’habitude coûteuse d’ouvrir des sessions TLS parallèles pour des ressources hébergées sur la même origine.

Lorsqu’il s’agit d’optimiser les performances TLS, la discussion porte presque toujours sur le trafic entrant (frontend), c’est-à-dire la façon dont les clients se connectent à vos serveurs de périphérie. Mais pour les architectures de microservices modernes, les réseaux d’entreprise et les applications cloud-native, le trafic sortant (egress) représente une pénalité de latence cachée considérable.

Chaque fois qu’un service interne lance un appel d’API sortant, récupère une dépendance tierce ou communique entre des clusters multirégions, il déclenche un nouveau handshake TLS.

Lorsque l’on ajoute le surcoût post-quantique à ces maillages de microservices internes, la latence cumulée augmente rapidement. Pour atténuer ce phénomène côté sortant :

• Déployer des proxys de transfert avec mutualisation des connexions : Placer un proxy de transfert sortant (ou un sidecar de service mesh comme Envoy) entre vos microservices internes et les points de terminaison externes permet de consolider et de mutualiser les connexions. Au lieu que chaque thread applicatif éphémère établisse son propre handshake TLS post-quantique vers un point de terminaison externe, le proxy de transfert maintient un pool de connexions TLS persistantes et durables.
• Keep-alives et reprise de session en sortie : Comme pour les proxys frontend, un réglage poussé de la reprise de session et des paramètres de keep-alive sur l’infrastructure de proxy sortant garantit que les applications internes bénéficient de connexions chaudes à faible latence.

En optimisant à la fois la diffusion frontend et l’infrastructure sortante, vous protégez vos utilisateurs finaux et votre architecture interne contre l’inévitable inflation en octets de la cryptographie post-quantique.