VPN post-quantique : WireGuard et OpenVPN en pratique

Un tunnel VPN est la pire cible possible pour un attaquant patient. Sur une terminaison TLS, il capture une session web, souvent sans grand intérêt une fois déchiffrée dix ans plus tard. Sur un tunnel site à site, il capture la réplication de base de données, le flux de sauvegarde vers le second site, l'authentification interne, les transferts de fichiers RH. Tout, en continu, sur des années.

C'est exactement le scénario « harvest now, decrypt later » appliqué à l'endroit où il fait le plus mal. La migration post-quantique côté TLS et SSH est aujourd'hui bien balisée. Côté VPN, le terrain est nettement plus accidenté : chaque protocole a pris un chemin différent, certains sont prêts pour la prod, d'autres relèvent encore du pilote. On trie ce qui s'active vraiment.

Trois différences structurelles.

D'abord, la durée de vie du secret. Une session HTTPS transporte des données dont la valeur s'effondre avec le temps. Un tunnel entre deux sites transporte des données dont la confidentialité doit tenir aussi longtemps que l'entreprise existe.

Ensuite, le contrôle des deux extrémités. Sur du web public, on subit le parc client. Sur un VPN d'entreprise, on possède les deux bouts, donc on peut imposer un algorithme sans se soucier du repli. Ça supprime la moitié des problèmes de compatibilité qui plombent la migration TLS.

Enfin, le transport. TLS vit sur TCP, qui segmente sans se poser de questions. WireGuard et IKEv2 vivent sur UDP, où un message de handshake qui dépasse le MTU se fragmente ou se perd. Or les clés publiques post-quantiques sont grosses. Une clé publique ML-KEM-1024 fait 1568 octets à elle seule, au-delà de ce qu'on considère comme sûr en payload UDP non fragmenté. C'est cette contrainte, pas la cryptographie, qui a dicté la conception de toutes les solutions qui suivent.

WireGuard n'a pas de mode post-quantique. Il a un PSK, et c'est un choix de conception assumé depuis l'origine. Le handshake Noise IKpsk2 mélange une clé pré-partagée symétrique de 256 bits dans la dérivation, en plus du résultat de l'échange Curve25519. Un attaquant qui casse la partie courbe elliptique avec une machine quantique ne récupère rien sans le PSK, et l'algorithme de Grover ne fait tomber ce PSK qu'à 128 bits de sécurité effective. Autrement dit : hors de portée.

Sur le papier, c'est réglé. En prod, c'est là que ça se complique.

Le PSK est statique. Il faut le transporter hors bande jusqu'aux deux pairs, et il reste identique pendant toute sa durée de vie. S'il fuite un jour, tout le trafic capturé depuis le déploiement devient déchiffrable dès qu'une machine quantique existe. La protection post-quantique de WireGuard repose donc entièrement sur la discipline de gestion d'un secret partagé, sans rotation automatique et sans forward secrecy sur ce secret.

Le PSK est aussi par paire de pairs. Sur un tunnel entre deux points, c'est trivial. Sur un maillage de trente pairs, on parle de plusieurs centaines de secrets à générer, distribuer et faire tourner. C'est le genre de tâche qu'on ne fait jamais correctement à la main, et une des raisons pour lesquelles un plan de contrôle comme Headscale devient indispensable dès qu'on dépasse quelques nœuds.

La règle qu'on applique : sur un tunnel WireGuard qui transporte des données sensibles à longue durée de vie, le PSK n'est pas optionnel. Il se génère avec wg genpsk, se pose dans la section du pair, et se documente comme un secret de production à part entière, avec un propriétaire et une date de rotation. Le reste du réglage du tunnel, MTU, keepalive, routage, suit les bonnes pratiques WireGuard habituelles. Un PSK ajouté ne change rien au plan de données.

Rosenpass part exactement de cette faiblesse. L'idée est simple et élégante : ne pas toucher à WireGuard, mais négocier le PSK en continu par un canal post-quantique séparé.

Le démon tourne à côté de WireGuard, exécute son propre échange de clés post-quantique, et pousse le résultat dans le PSK du pair via l'interface d'administration de WireGuard. Toutes les deux minutes, un nouvel échange, un nouveau PSK. Le partage des rôles est net : Rosenpass assure la sécurité post-quantique, WireGuard assure la sécurité pré-quantique et tout le plan de données.

La construction cryptographique mérite qu'on s'y arrête, parce qu'elle explique les contraintes opérationnelles. Rosenpass combine deux mécanismes aux hypothèses de sécurité indépendantes : Classic McEliece pour les clés statiques et ML-KEM (l'ancien Kyber) pour l'éphémère. Classic McEliece est un cryptosystème fondé sur les codes correcteurs, avec des décennies de cryptanalyse derrière lui, choisi ici pour son conservatisme. Son prix est brutal : avec le jeu de paramètres 460896, la clé publique pèse 524160 octets, soit environ 512 Ko.

Un demi-mégaoctet de clé publique dans un handshake UDP, ce serait rédhibitoire. Sauf que ces clés McEliece sont statiques et pré-partagées entre les pairs, pas transmises à chaque négociation. Ce qui circule, c'est le chiffré, qui ne fait que 188 octets, plus les éléments ML-KEM qui restent de taille raisonnable. Résultat : les deux messages du handshake Rosenpass tiennent dans un MTU UDP standard, sans fragmentation.

Côté performance, la conséquence est celle qu'on veut : une fois le handshake passé, le trafic est du WireGuard pur. Zéro overhead sur le débit, zéro latence ajoutée sur le plan de données. Le coût se limite à un échange plus lourd toutes les deux minutes, sur le plan de contrôle.

Le code est en Rust, sous double licence MIT et Apache 2.0, et les propriétés de sécurité du cœur du protocole ont fait l'objet d'une vérification formelle, ce qui est rare à ce niveau. Un audit indépendant a été mené par Radically Open Security, rapport publié début 2024.

Voilà le point où l'enthousiasme doit s'arrêter. Rosenpass est toujours en pre-1.0, autour de la 0.2.x à mi-2026. Ce n'est pas un détail de numérotation, c'est une déclaration d'intention du projet sur la stabilité de ses interfaces.

L'intégration la plus aboutie côté produit est celle de NetBird, qui expose Rosenpass derrière un simple netbird up --enable-rosenpass. Sa documentation est honnête, et les limites qu'elle liste sont les vraies limites opérationnelles du protocole aujourd'hui :

• La fonctionnalité est explicitement qualifiée d'expérimentale.
• Elle n'est pas supportée sur mobile.
• Un pair avec Rosenpass activé ne communique qu'avec d'autres pairs Rosenpass, sauf à passer en mode permissif.

Ce dernier point est le piège classique. Le mode permissif rétablit la compatibilité avec les pairs non équipés, donc il rend le déploiement progressif possible, donc tout le monde l'active. Mais un pair en mode permissif qui négocie avec un pair sans Rosenpass retombe silencieusement sur du WireGuard classique. On croit avoir migré la flotte, on en a migré une partie et on ne sait pas laquelle. Si vous activez le mode permissif, supervisez explicitement quels pairs ont une session Rosenpass établie, sinon la protection est une croyance.

Verdict : Rosenpass est le seul mécanisme sérieux qui donne à WireGuard une vraie rotation post-quantique, mais on ne le pose pas aujourd'hui sur un maillage de production critique sans plan de repli. Sur un tunnel dédié entre deux sites, avec un périmètre fermé et une supervision propre, c'est défendable dès maintenant.

Le canal de contrôle d'OpenVPN est du TLS, ce qui lui fait hériter gratuitement de tout le travail déjà fait sur le web. En TLS 1.3, avec OpenSSL 3.5, le groupe hybride X25519MLKEM768 fait partie de la liste par défaut. OpenVPN 2.7, publié en février 2026, apporte le support TLS 1.3 avec les bibliothèques récentes. La combinaison OpenVPN 2.7 compilé contre OpenSSL 3.5 négocie donc un échange de clés hybride sans configuration particulière, et le principe est identique à celui du web : la clé de session dérive des deux échanges, casser X25519 ou casser ML-KEM ne suffit pas.

Trois précautions avant de crier victoire.

La négociation par défaut ne se vérifie pas, elle se prouve : lire les logs du canal de contrôle et confirmer le groupe réellement négocié des deux côtés. Les variantes hybrides existent aussi en SecP256r1MLKEM768 et SecP384r1MLKEM1024 ; si votre configuration force une liste de groupes, X25519MLKEM768 doit y figurer explicitement.

La version d'OpenSSL contre laquelle le binaire de votre distribution est lié compte plus que la version d'OpenVPN. Un OpenVPN 2.7 packagé contre OpenSSL 3.0 n'a aucune capacité post-quantique. C'est le premier point à contrôler.

Enfin, le ClientHello gonfle. Sur du TCP, ça passe. Sur du UDP, ce qui est le mode recommandé pour les performances, un handshake plus gros traverse des équipements intermédiaires qui n'aiment ni la fragmentation ni les paquets inhabituels. Le réglage de fragment et mssfix d'une configuration OpenVPN sous Linux redevient un sujet, alors qu'on l'avait oublié depuis des années.

Un détail qui n'en est pas un : les certificats OpenVPN restent signés en RSA ou ECDSA. La protection porte sur l'échange de clés, pas sur l'authentification. C'est le bon arbitrage, parce qu'une signature ne se déchiffre pas rétroactivement, donc la menace temporelle y est bien moindre.

Si votre parc est en IPsec, c'est le chemin le plus propre sur le plan des standards. La RFC 9370 étend IKEv2 pour supporter plusieurs mécanismes d'encapsulation de clés, jusqu'à sept couches de KEM additionnelles combinées à l'échange Diffie-Hellman d'origine. Le problème du gabarit UDP y est traité de front, avec une phase d'échange supplémentaire, IKE_INTERMEDIATE, introduite avant IKE_AUTH précisément pour transporter du matériel de clé volumineux sans casser la négociation.

strongSwan implémente ce cadre, et depuis les versions 6.0 l'intégration est directe, sans passer par le greffon liboqs. La configuration ressemble à ceci, avec ML-KEM-768 comme couche additionnelle derrière une courbe classique :

ike = aes256-sha384-ecp384-ke1_mlkem768!

Le préfixe ke1_ désigne le premier échange de clés additionnel au sens de la RFC 9370. La syntaxe dit exactement ce qu'elle fait : de l'hybridation explicite, lisible dans la configuration, auditable.

La recommandation tranchée, dans l'ordre où on l'applique sur les infrastructures qu'on opère.

Un, inventoriez vos terminaisons VPN et la version de bibliothèque cryptographique derrière chacune. La question n'est pas « est-ce qu'on fait du post-quantique », c'est « quelle version d'OpenSSL est liée à ce binaire OpenVPN ». Tant que cette liste n'existe pas, tout plan de migration est de la fiction.

Deux, sur OpenVPN et strongSwan, activez et prouvez l'hybridation. Le coût est nul, le gain est immédiat, la seule difficulté réelle est la fragmentation UDP et elle se teste en une après-midi.

Trois, sur WireGuard, posez un PSK partout où le tunnel transporte des données à longue durée de vie. Aujourd'hui, sans attendre Rosenpass. C'est une protection réelle, standard, sans dépendance à un projet pre-1.0.

Quatre, montez un pilote Rosenpass sur un tunnel non critique, pour apprendre le protocole avant d'en avoir besoin en urgence. Quand le projet passera en 1.0, vous saurez déjà l'exploiter.

Ce qui compte n'est pas d'être post-quantique partout demain. C'est de savoir, tunnel par tunnel, ce qui est protégé et ce qui ne l'est pas. Un parc où trois tunnels sur quarante sont réellement hybridés, sans que personne ne sache lesquels, ne vaut pas mieux qu'un parc entièrement classique : il coûte juste plus cher en illusion.

Si vos tunnels site à site transportent de la réplication ou de la sauvegarde entre deux emplacements distants, comme entre le DC Fullsave de Toulouse et le site TDF de Bordeaux, l'exposition « harvest now, decrypt later » est déjà là et se mesure en années de trafic capturable. On peut auditer vos terminaisons VPN et activer l'hybridation là où elle tient en production, en prouvant le repli plutôt qu'en le supposant.

• Rosenpass : site officiel du protocole, description de l'architecture side-car, des algorithmes Classic McEliece et ML-KEM, et du statut du projet.
• Classic McEliece : implementation : source primaire pour les tailles de clés et de chiffrés des jeux de paramètres, dont le 460896.
• NetBird : enable quantum-resistance : documentation d'une intégration Rosenpass en production, limites déclarées et mode permissif.
• Post-quantum hybrid key exchange with ML-KEM in IKEv2 : draft IETF sur l'usage de ML-KEM dans IKEv2, dans le cadre défini par la RFC 9370.
• draft-wang-hybrid-kem-ikev2-frodo : rappel du cadre RFC 9370, des sept couches de KEM et de la phase IKE_INTERMEDIATE.
• OpenSSL Corporation : post-quantum readiness : état du support ML-KEM, ML-DSA et SLH-DSA dans OpenSSL 3.5.
• OpenVPN : Changes.rst : changelog officiel du projet, support TLS 1.3 et évolutions du canal de données en 2.7.