Tunnels locaux à l’épreuve du quantique : préparer votre environnement de développement pour la cryptographie post-quantique

L’informatique quantique est une étape clé pour les équipes de sécurité et les organismes de normalisation. Le NIST a fixé une date pour la suppression des algorithmes de clé publique actuels, et les grands CDN ainsi que les systèmes d’exploitation négocient déjà par défaut un échange de clés post-quantique. Une partie de la pile technique reçoit peu d’attention dans cette migration : le tunnel de développement local.

Les développeurs utilisent des tunnels pour exposer localhost aux fournisseurs de webhooks, aux appareils de test mobile, et aux clients qui examinent une version de mise en scène. Un tunnel est un canal TLS protégé, héritant donc des mêmes vulnérabilités cryptographiques qu’une autre connexion TLS. Il transporte aussi souvent des données sensibles, comme des clés API, des jetons de session, ou des payloads copiés de systèmes réels.

Ce guide explique ce qu’un ordinateur quantique pourrait compromettre dans un tunnel et ce qu’il ne pourrait pas. Il détaille aussi ce que les standards indiquent aujourd’hui et comment fonctionne l’échange de clés hybride en TLS 1.3. Enfin, il examine quels outils de tunneling supportent déjà l’échange de clés post-quantique et quel est le coût en performance.

---

1. Ce qui est réellement à risque dans un tunnel

L’anatomie d’une connexion tunnel

Un tunnel comporte deux segments :

1. Segment public : un navigateur, une application mobile ou un expéditeur de webhook se connecte via TLS à l’edge public du fournisseur de tunnel.
2. Segment agent : un démon client sur votre ordinateur maintient une connexion sortante longue durée vers le même edge, et les requêtes sont multiplexées dessus.

Chaque segment est protégé par sa propre poignée de main cryptographique. En TLS 1.3, les clés de session proviennent d’un échange de clés (EC)DHE éphémère, généralement X25519. Le certificat du serveur est vérifié avec une signature comme RSA ou ECDSA. Un tunnel ne protégeant qu’un seul de ces segments laisse l’autre classique. L’un ou l’autre peut être la faiblesse.

Pourquoi l’algorithme de Shor est important ici

L’algorithme de Shor, exécuté sur un ordinateur quantique suffisamment tolérant aux fautes, brise RSA, Diffie-Hellman sur corps fini, et la cryptographie à courbe elliptique, y compris X25519 et ECDSA. Les chiffrements symétriques comme AES-256 et ChaCha20 ne sont pas vulnérables, donc la partie de chiffrement symétrique d’un tunnel n’a pas besoin d’être remplacée.

Aucune machine capable de cela n’existe aujourd’hui. Les estimations de ce qu’il faudrait ont été revues à la baisse. En 2019, Craig Gidney et Martin Ekerå estimaient qu’il faudrait environ 20 millions de qubits bruyants pour factoriser RSA-2048. En mai 2025, Gidney a publié une nouvelle estimation, inférieure à un million de qubits bruyants et moins d’une semaine de calcul. Ce sont des estimations de ressources pour une machine que personne n’a construite, mais elles expliquent pourquoi les horizons de planification se sont raccourcis.

Store-now-decrypt-later (SNDL)

SNDL signifie enregistrer le trafic chiffré maintenant pour le déchiffrer une fois qu’un ordinateur quantique capable sera disponible. La guidance gouvernementale pour la migration, y compris le projet de transition du NIST, considère cela comme une raison de migrer d’abord l’échange de clés. Je n’ai pas connaissance d’un cas documenté où quelqu’un aurait archivé spécifiquement le trafic de tunnel de développeur. La question porte sur le risque : si une session capturée est protégée uniquement par un échange de clés classique, elle est exposée dès qu’un ordinateur quantique apparaît, peu importe quand elle a été enregistrée.

Cela concerne principalement l’échange de clés. Les signatures et certificats ne sont pas une cible SNDL, car falsifier une signature n’aide qu’un attaquant capable de le faire en direct. C’est pourquoi l’échange de clés a été migré avant l’authentification dans l’industrie.

Que cela ait de l’importance pour votre tunnel dépend de ce qui le traverse et de la durée de confidentialité requise. Payloads de webhook avec des identifiants en direct, données clients copiées dans un environnement de test, ou code source non publié restent sensibles potentiellement une décennie.

---

2. Standards : où en sont les choses en octobre 2026

Le 13 août 2024, le NIST a publié ses trois premiers standards post-quantiques :

Standard	Algorithme	Origine	Objectif
FIPS 203	ML-KEM	CRYSTALS-Kyber	Encapsulation de clé (échange de clés)
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Signatures numériques
FIPS 205	SLH-DSA	SPHINCS+	Signatures numériques basées sur hachage

Deux autres éléments sont en cours. FN-DSA, basé sur Falcon, est spécifié dans FIPS 206, encore en draft, avec une finalisation prévue vers fin 2026 ou début 2027. En mars 2025, le NIST a aussi choisi HQC, un KEM basé sur du code, comme solution de secours en plus de ML-KEM.

La sécurité de ML-KEM repose sur la difficulté du problème Module Learning With Errors sur des réseaux structurés. C’est l’algorithme adopté par TLS, SSH, et VPN pour l’échange de clés.

La timeline de migration

Le rapport de draft IR 8547 du NIST (publié le 12 novembre 2024) propose de déprécier après 2030 les algorithmes de clé publique vulnérables au quantique avec une sécurité de 112 bits, comme RSA-2048 et P-256 ECC, puis de les interdire après 2035. Ce n’est qu’une proposition, mais la politique fédérale et la législation d’achat ont été construites autour de ces dates. La suite CNSA 2.0 de la NSA pour les systèmes de sécurité nationale fixe ses propres échéances plus précoces, et nomme ML-KEM-1024 et ML-DSA-87 comme algorithmes.

---

3. Pourquoi l’échange de clés hybride est la méthode courante

Un échange de clés hybride combine un échange classique (X25519) et un échange post-quantique (ML-KEM-768) dans la même poignée de main, et dérive la clé de session à partir des deux. Un attaquant doit casser les deux pour récupérer la clé. Cela couvre deux modes d’échec : une faille dans le code ou la mathématique post-quantique, ou une rupture quantique future de la courbe classique.

Les gouvernements ne sont pas tous d’accord sur la nécessité de l’hybride :

• Allemagne (BSI) et France (ANSSI) exigent ou favorisent fortement l’hybride avec des algorithmes classiques.
• La NSA indique qu’elle ne requiert pas l’hybride pour la sécurité nationale, mais l’accepte pour l’interopérabilité, avec l’objectif de passer aux algorithmes CNSA 2.0 d’ici la date fixée.
• Le NIST rédige des recommandations pour combiner des schémas d’établissement de clés (SP 800-227), sans imposer l’hybride.

L’hybride est donc la pratique dominante sur Internet public, notamment en TLS, mais ce n’est pas une obligation universelle.

Fonctionnement en TLS 1.3

Le groupe hybride le plus utilisé est X25519MLKEM768. Il est défini dans un brouillon IETF, draft-ietf-tls-ecdhe-mlkem, encore en révision (version 05, mai 2026). Le brouillon définit aussi SecP256r1MLKEM768 et SecP384r1MLKEM1024. Lors de l’échange :

1. La clé partagée du client est la clé d’encapsulation ML-KEM-768 suivie de sa clé publique éphémère X25519.
2. La clé partagée du serveur est le ciphertext ML-KEM suivi de sa clé publique éphémère X25519.
3. Les deux côtés calculent la secret partagé ML-KEM et X25519, les concatènent, et alimentent le processus de dérivation de clé TLS 1.3 comme entrée (EC)DHE.

Comme la chaîne de clés ne change pas, le reste de la poignée de main et le chiffrement symétrique fonctionnent comme avant.

Tailles

Échange de clés	Clé client	Clé serveur
X25519	32 octets	32 octets
ML-KEM-768 (clé d’encapsulation / ciphertext)	1 184 octets	1 088 octets
X25519MLKEM768 (hybride)	1 216 octets	1 120 octets

Comparé à X25519 seul, l’hybride ajoute 2 272 octets (environ 2,2 KiB) pour les deux clés.

---

4. Implications pour les outils de tunneling

Le support post-quant varie beaucoup selon les outils, vérifiez donc chaque cas plutôt que de supposer.

Tunnels SSH inversés. OpenSSH 10.0, sorti le 9 avril 2025, a fait de mlkem768x25519-sha256 l’accord de clés par défaut pour le client. Si vous utilisez ssh -R pour exposer un port local via un serveur récent, l’échange est déjà hybride post-quantique par défaut. La version 10.1 ajoute un avertissement si la connexion n’utilise pas un échange de clés post-quantique.

Cloudflare Tunnel. Cloudflare a introduit un mode post-quantique pour cloudflared en octobre 2022, utilisant les hybrides Kyber prévus par le brouillon. Lorsqu’activé, cloudflared ne revient pas à une connexion non post-quantique. Au lancement, Cloudflare a noté que la connexion de contrôle et l’authentification n’étaient pas encore post-quantiques. En février 2026, plus de 60% du trafic client sur leur réseau utilisait déjà le chiffrement post-quantique, contre moins de 3% début 2024. Vérifiez la documentation pour le comportement précis de votre version.

Outils basés sur WireGuard. La documentation de Tailscale indique que leur implémentation WireGuard n’est pas post-quantique. Elle explique aussi que WireGuard évite délibérément l’agilité protocolaire, donc ML-KEM ne peut pas être simplement intégré. Si votre outil utilise WireGuard, demandez au fournisseur ses plans.

Outils que vous développez ou faites tourner en Go. Go 1.24 (février 2025) a activé par défaut X25519MLKEM768 dans crypto/tls quand Config.CurvePreferences est nil. Un client ou un edge tunnel basé sur Go 1.24 ou plus récent négocie automatiquement le groupe hybride sans modification de code. Kubernetes v1.33, construit avec Go 1.24, a adopté cette configuration. Vous pouvez désactiver avec GODEBUG=tlsmlkem=0, utile si un middlebox ou serveur buggué mal gère la poignée de main plus grande.

Autres fournisseurs. Je n’ai pas trouvé de documentation publique confirmant le support de l’échange de clés post-quantique pour plusieurs autres services de tunneling populaires. Si vous en utilisez un, demandez au fournisseur si la clé publique et la clé agent négocient un groupe hybride, et ce qui se passe en fallback.

Un point architectural à vérifier

Si un fournisseur termine TLS à son edge, le segment public et le segment agent sont des sessions TLS séparées. La protection post-quantique sur l’un ne protège pas l’autre, donc il faut les deux. Même avec les deux segments protégés, l’edge du fournisseur voit en clair. Pour des données vraiment sensibles, le chiffrement de bout en bout dans le tunnel est plus important que le choix de l’échange de clés sur chaque segment.

---

5. Configurer TLS hybride en Go

Pour Go 1.24 et plus, la configuration par défaut privilégie déjà le groupe hybride. Pour l’expliciter, par exemple pour la documentation ou pour le verrouillage, faites ceci :

package main

import (
	"crypto/tls"
	"log"
	"net/http"
)

func newServer() *http.Server {
	cfg := &tls.Config{
		MinVersion: tls.VersionTLS13,
		// Favoriser le groupe hybride post-quantique ; garder X25519 classique
		CurvePreferences: []tls.CurveID{
			tls.X25519MLKEM768,
			tls.X25519,
		},
	}
	return &http.Server{
		Addr:      ":443",
		TLSConfig: cfg,
	}
}

func main() {
	srv := newServer()
	log.Fatal(srv.ListenAndServeTLS("cert.pem", "key.pem"))
}

Deux points importants :

• Les suites de chiffrement TLS 1.3 ne sont pas configurables dans crypto/tls de Go, donc il n’est pas nécessaire de spécifier CipherSuites. La sélection du groupe de clés détermine la protection post-quantique.
• Maintenir tls.X25519 en fallback permet à d’anciens clients de se connecter, mais ouvre aussi la possibilité d’un downgrade vers un échange classique. Si vous contrôlez les deux extrémités, comme votre propre client et edge, vous pouvez désactiver le fallback et rendre le groupe hybride obligatoire. Cloudflare a adopté cette approche avec son drapeau --post-quantum.

Le groupe hybride ne s’applique qu’à TLS 1.3. Un client négociant TLS 1.2 aura une poignée de main purement classique, d’où l’importance de MinVersion: tls.VersionTLS13.

---

6. Performance : ce que montrent les mesures

Le coût de l’échange de clés hybride provient presque entièrement des octets supplémentaires dans la poignée de main, pas du calcul. Les chiffres ci-dessous proviennent de déploiements à grande échelle, pas d’un benchmark spécifique à un tunnel, donc à prendre comme indicatif.

• Latence de la poignée de main. Des ingénieurs Chrome ont rapporté sur une liste IETF que l’ajout de Kyber à la poignée de main TLS augmentait la latence d’environ 4% sur desktop et 9% sur Android en médiane, avec des valeurs beaucoup plus élevées au 95e percentile. Cloudflare a mesuré qu’ajouter 1 Ko dans la réponse du serveur augmentait la latence médiane de la poignée de main HTTPS d’environ 1,5%. Ces pourcentages concernent uniquement la poignée de main, pas le chargement complet de page ou la requête.
• Compatibilité middlebox et serveur. La taille accrue du ClientHello peut provoquer des bugs dans des serveurs ou middleboxes mal écrits. Cloudflare a constaté que 0,34% des origines scannées ne terminaient pas la poignée de main avec un partage de clé post-quantique en premier. La documentation de Go indique tlsmlkem=0 comme solution pour les serveurs défaillants face aux grands enregistrements.
• Coût de réessai. Si un client se trompe sur le groupe supporté par le serveur, TLS 1.3 nécessite un round trip supplémentaire (HelloRetryRequest). Cloudflare a réduit ces réessais de 52% à 3,7% en mesurant la préférence de chaque origine, ce qui a enlevé plus de 150 ms en p90 de latence de poignée de main.
• Après la poignée de main. Le transfert de données en masse est protégé par le même chiffre symétrique qu’avant (AES-GCM ou ChaCha20-Poly1305), donc le débit par octet ne change pas. AWS a analysé que le coût supplémentaire est payé une seule fois par connexion, puis amorti sur la session, et le pooling de connexions réduit encore l’impact.

Pour les tunnels, c’est avantageux. La branche agent est généralement une connexion multiplexée longue durée, donc le coût de la poignée de main n’est payé qu’une fois. Pour la branche publique, le coût est réparti sur chaque nouvelle connexion, mais les webhooks et navigateurs réutilisant les connexions le paient moins souvent. Je n’ai pas de mesure précise en millisecondes pour les aperçus de tunnel, et méfiez-vous de tout article citant un chiffre sans préciser la configuration de test. Si cela vous concerne, mesurez votre tunnel avec le groupe hybride activé ou désactivé.

---

7. Étapes pratiques pour votre environnement

1. Inventoriez vos tunnels. Listez tous les outils que vous utilisez pour exposer des services locaux (SSH, fournisseur commercial, agent auto-hébergé) et vérifiez leur documentation pour le support de ML-KEM ou X25519MLKEM768 sur chaque segment.
2. Privilégiez les outils qui utilisent par défaut l’hybride. OpenSSH 10.0 ou plus récent et Go 1.24 ou plus récent le font déjà. Mettez à jour clients et serveurs plutôt que de configurer manuellement.
3. Vérifiez, ne supposez pas. Inspectez une poignée de main réelle côté client avec OpenSSL ou une capture réseau pour confirmer que le groupe négocié est hybride. Considérez un fallback silencieux à X25519 comme une anomalie.
4. Exigez TLS 1.3 si vous contrôlez les deux extrémités. Les poignées de main TLS 1.2 sont toujours classiques.
5. Ne vous fiez pas uniquement au chiffrement transport pour la confidentialité. Gardez les identifiants en production hors des environnements locaux, utilisez des tokens à durée courte, et évitez d’envoyer des données clients réelles via un tunnel. Cela limite les dégâts en cas d’enregistrement.
6. Planifiez l’authentification séparément. Les certificats et signatures post-quantiques sont plus difficiles à faire migrer, et ne sont pas encore déployés massivement. Les certificats à courte durée sont une bonne pratique, mais ne résolvent pas le store-now-decrypt-later, qui cible l’échange de clés.
7. Restez agile en crypto. FN-DSA et HQC sont encore en cours de standardisation, et le hybride TLS reste un brouillon Internet. Choisissez des outils pouvant changer d’algorithme via une configuration ou une mise à jour plutôt qu’un rebuild.

---

Conclusion

Le tableau pratique pour les tunnels locaux est meilleur que ce que laissent penser les gros titres. L’échange de clés post-quantique est standardisé, déployé par défaut dans des logiciels largement utilisés comme OpenSSH 10 et Go 1.24, et son coût en handshake est modéré. Le reste du travail consiste surtout à vérifier et choisir ses outils. Vérifiez que chaque segment de votre tunnel négocie un groupe hybride, gardez les secrets hors du trafic tunnelé, et considérez l’authentification post-quantique comme la prochaine étape plutôt que la première.

---

Références

• NIST FIPS 203, 204, 205 (finalisés le 13 août 2024) et état de FIPS 206 et HQC : Encryption Consulting – Décodage des standards PQC du NIST; Diapositives d’aperçu NIST PQC
• Rapport IR 8547 du NIST : Encryption Consulting – Explication du NIST IR 8547
• Brouillon de l’échange hybride TLS : draft-ietf-tls-ecdhe-mlkem
• Tailles ML-KEM-768 : facil.io ML-KEM-768 référence
• Positions politiques hybrides (NSA, BSI, ANSSI) : PostQuantum.com – Exigences PQC mondiales; PQShield – mise à jour CNSA 2.0
• Go 1.24 par défaut pour l’hybride : Documentation GODEBUG de Go; Blog Kubernetes – PQC dans Kubernetes
• Notes de version OpenSSH 10.0 : openssh.com
• Mode post-quantique de Cloudflare Tunnel : Présentation du tunnel post-quantique Cloudflare
• Données d’adoption Cloudflare : Plus de transparence sur l’usage PQC
• Tailscale et WireGuard : Documentation cryptographie post-quantique Tailscale
• Données de latence handshake : Liste TLS IETF – mesures Chrome et Cloudflare; AWS Security Blog – Performance TLS hybride PQC; InfoQ – Préférences TLS Cloudflare
• Estimation RSA-2048 : Gidney, “Comment factoriser RSA 2048 bits avec moins d’un million de qubits bruyants”