Hybrid TLS : combiner cryptographie classique et post-quantique pour une transition progressive

Hybrid TLS : combiner cryptographie classique et post-quantique pour une transition progressive
TLS & Protocoles

Hybrid TLS : combiner cryptographie classique et post-quantique pour une transition progressive

Publié le 15 mars 2025  ·  ⏱ 12 min de lecture  ·  Sécurité réseau

Le déploiement d’une cryptographie purement post-quantique en production est encore prématuré pour la grande majorité des organisations : les bibliothèques TLS sont en cours de finalisation, la compatibilité avec tous les équipements réseau n’est pas garantie, et les algorithmes PQC, bien que standardisés, accumulent moins d’années d’analyse cryptographique que RSA ou ECC. La solution intermédiaire recommandée par le NIST, l’ANSSI et l’IETF est le Hybrid TLS : combiner un échange de clés classique (ECDHE) avec un échange de clés post-quantique (ML-KEM) dans la même session TLS.

🔐 Principe de sécurité hybride : Dans un mode hybride, la sécurité de la session est garantie par le meilleur des deux algorithmes. Si ML-KEM est compromis (faille algorithmique découverte), ECDHE protège toujours la session. Si ECDHE est cassé par un ordinateur quantique, ML-KEM assure la protection. C’est une couverture à double filet.

Comment fonctionne le Hybrid TLS 1.3

Dans TLS 1.3 classique, l’échange de clés se fait via ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Dans le mode hybride, deux échanges sont réalisés simultanément : un ECDHE classique (courbe X25519 ou P-256) et un ML-KEM (Kyber-768 ou Kyber-1024). Les secrets dérivés des deux échanges sont combinés via une fonction KDF (Key Derivation Function) — généralement HKDF — pour produire le secret de session final.

L’IETF a défini les groupes hybrides dans le draft draft-ietf-tls-hybrid-design. Les identifiants de groupes notables sont :

  • X25519MLKEM768 : X25519 + ML-KEM-768 (recommandé, niveau sécurité 3)
  • SecP256r1MLKEM768 : P-256 + ML-KEM-768 (pour compatibilité FIPS)
  • X25519MLKEM1024 : X25519 + ML-KEM-1024 (niveau sécurité 5)

Configuration OpenSSL 3.x avec provider OQS

# Installation du provider Open Quantum Safe pour OpenSSL 3.x
git clone https://github.com/open-quantum-safe/oqs-provider
cd oqs-provider && cmake -B build && cmake --build build
sudo cmake --install build

# Configuration openssl.cnf pour activer le provider OQS
[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[oqsprovider_sect]
module = /usr/local/lib/ossl-modules/oqsprovider.so
activate = 1

# Test d'un serveur TLS hybride
openssl s_server -cert server.crt -key server.key \
  -groups X25519MLKEM768 -tls1_3 -port 4433

# Test client hybride
openssl s_client -connect localhost:4433 \
  -groups X25519MLKEM768 -tls1_3

Configuration nginx avec TLS hybride

# nginx.conf — activation des ciphers hybrides PQC
server {
    listen 443 ssl;
    server_name votredomaine.fr;

    ssl_certificate     /etc/ssl/certs/server-hybrid.crt;
    ssl_certificate_key /etc/ssl/private/server-hybrid.key;
    
    # Protocole TLS 1.3 uniquement
    ssl_protocols TLSv1.3;
    
    # Groupes hybrides : hybride PQC en priorité, classique en fallback
    ssl_ecdh_curve X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256;
    
    # Optimisations TLS standard
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
    add_header Strict-Transport-Security "max-age=31536000" always;
}

Impact sur les performances

ParamètreTLS 1.3 classique (X25519)Hybrid TLS (X25519MLKEM768)Différence
Taille du ClientHello (ajout KEM)~300 octets~1500 octets+1200 octets
Taille du ServerHello~200 octets~1200 octets+1000 octets
Latence handshake (LAN)~0.5ms~0.8ms+60%
Latence handshake (WAN 50ms RTT)~100ms~102ms+2%
CPU serveur (req/s)Référence-5% à -15%Négligeable
Impact sur les transferts de données00Aucun

L’impact sur les performances est principalement visible dans la phase de handshake, et plus particulièrement sur les connexions à faible débit (mobile 3G/4G, IoT). Sur des connexions WAN standards, l’augmentation de latence est imperceptible pour l’utilisateur final. Le principal défi est la fragmentation des paquets lors du handshake — les messages Hybrid TLS dépassent souvent la MTU standard (1500 octets), nécessitant plusieurs fragments TCP.

Support navigateurs et équipements réseau

ComposantSupport Hybrid TLSGroupe supporté
Chrome 124+✅ NatifX25519MLKEM768 (expérimental puis stable)
Firefox 128+✅ NatifX25519MLKEM768
Safari / WebKit🔄 En développementPrévu 2025
OpenSSL 3.x + OQS provider✅ Via pluginTous groupes hybrides
BoringSSL (Google)✅ IntégréX25519MLKEM768
Cloudflare CDN✅ DéployéX25519MLKEM768
AWS CloudFront✅ DisponibleX25519MLKEM768
Pare-feux next-gen (Palo Alto, Fortinet)⚠️ PartielSelon version firmware

FAQ — Hybrid TLS

Le Hybrid TLS casse-t-il l’inspection SSL des firewalls ?

C’est l’un des principaux défis opérationnels. Les solutions d’inspection SSL (MITM proxies) dans les firewalls doivent supporter les groupes hybrides pour ne pas rejeter les connexions. Les firmwares récents de Palo Alto Networks, Fortinet et Check Point commencent à intégrer ce support, mais beaucoup d’équipements plus anciens devront être mis à jour ou contournés pour les connexions hybrides PQC.

Doit-on aussi mettre à jour les certificats TLS pour le mode hybride ?

Pas nécessairement dans un premier temps. Le mode hybride s’applique à l’échange de clés (key agreement) — les certificats peuvent rester en ECDSA ou RSA pour l’authentification. La migration des certificats vers ML-DSA (algorithme de signature post-quantique) est une étape séparée. Commencez par les hybrid key exchange, qui sont les plus impactants contre les attaques « harvest now, decrypt later ».

Comment tester si mon serveur utilise bien le Hybrid TLS ?

Utilisez l’outil openssl s_client avec l’option -groups X25519MLKEM768 et vérifiez le groupe négocié dans la sortie. L’outil en ligne SSL Labs de Qualys devrait bientôt intégrer des tests PQC. Vous pouvez aussi utiliser Wireshark pour capturer le handshake TLS et vérifier l’identifiant du groupe d’échange de clés dans le ClientHello.

Conclusion : déployez le Hybrid TLS maintenant

Le Hybrid TLS X25519MLKEM768 est déployable en production dès aujourd’hui pour la plupart des applications web. Chrome, Firefox et les principaux CDN le supportent. La fenêtre d’implémentation est brève : si vos adversaires interceptent vos communications TLS aujourd’hui en attendant des ordinateurs quantiques, le Hybrid TLS met fin à cette menace. C’est l’action post-quantique avec le meilleur rapport impact/effort disponible en 2025.

Dans une stratégie de cybersécurité moderne, la transition vers la cryptographie post-quantique devient un enjeu critique pour les entreprises. Les organisations doivent anticiper ces évolutions afin de garantir la sécurité de leurs systèmes face aux futures menaces.

Pour approfondir ces sujets, consultez nos ressources sur : la cybersécurité post-quantique, les stratégies d’audit de sécurité, ainsi que les mécanismes de migration cryptographique.