La cryptographie post-quantique (PQC) a cessé d'être un sujet de recherche. OpenSSL 3.5 embarque nativement les ML-KEM, ML-DSA et SLH-DSA du NIST, et fait passer l'échange de clés TLS par défaut au groupe hybride post-quantique X25519MLKEM768. Toute connexion TLS entre deux extrémités sous OpenSSL 3.5 négocie un échange de clés post-quantique sans aucune configuration explicite de l'administrateur.

C'est déjà dans le trafic réel

Ce n'est pas une capacité de fiche technique. Chrome active ce groupe hybride par défaut depuis la version 124 (avril 2024), et le rapport de transparence de Cloudflare le situe à environ 30 % des connexions TLS 1.3. Une large part de vos visiteurs arrivent déjà avec la capacité PQC — reste à savoir si elle sera utilisée, ce qui dépend entièrement de votre côté.

Pourquoi maintenant plutôt que plus tard

La raison tient au principe « récolter maintenant, déchiffrer plus tard » : un attaquant enregistre aujourd'hui du trafic chiffré et le déchiffrera lorsque le matériel quantique aura mûri. Pour tout ce qui doit rester confidentiel des années, la menace existe dès aujourd'hui. La conception hybride est délibérément pragmatique : elle combine le X25519 classique et le ML-KEM-768 post-quantique, de sorte que la session reste sûre tant que l'un des deux tient. Basculer maintenant est donc peu risqué.

Déploiement sur un VPS

  • Vérifiez d'abord votre version : openssl version. La 3.5 est la branche LTS actuelle, prise en charge jusqu'en avril 2030 ; tout ce qui est plus ancien n'a pas de PQC natif.
  • Laissez la distribution vous fournir la 3.5 : Ubuntu 26.04 LTS embarque déjà un OpenSSL avec prise en charge post-quantique, c'est la voie la moins coûteuse. Compiler à la main sur une version ancienne signifie en assurer soi-même la maintenance et se révèle rarement rentable.
  • Confirmez que Nginx est lié à la nouvelle bibliothèque : nginx -V indique l'OpenSSL de compilation ; vérifiez ensuite que la bibliothèque partagée chargée à l'exécution est bien la 3.5. Les décalages sont fréquents.
  • Validez par une vraie poignée de main : exécutez openssl s_client -connect votredomaine:443 -groups X25519MLKEM768. Cela ne compte que si la poignée de main aboutit et négocie bien ce groupe.
  • Activez l'hybride, pas le post-quantique pur : les algorithmes purement post-quantiques n'ont pas accumulé le même recul opérationnel. L'hybride est le choix sain aujourd'hui.
  • Attendez-vous à des poignées de main plus volumineuses : le matériel de clé ML-KEM est nettement plus gros que ses équivalents à courbes elliptiques, ce qui peut ralentir la négociation sur des liens à pertes. Mesurez avant de vous engager.

Plateformes managées et serveur personnel

Le PQC illustre parfaitement une mise à niveau que l'on ne peut mener que si l'on possède la couche de terminaison TLS. Sur un hébergement mutualisé ou une plateforme managée fermée, vous attendez la feuille de route du fournisseur. Sur votre propre VPS, mettre à jour le système, passer à un OpenSSL plus récent, ajuster la directive ssl_conf_command de Nginx et vérifier la poignée de main relèvent de votre calendrier. SharkCloud propose des instances dédiées avec accès root dans plusieurs régions, pour prendre les devants sur ce type de mise à niveau plutôt que de faire la queue.