Ce qu'apporte la forward secrecy (confidentialité persistante) à TLS

La confidentialité persistante garantit que la compromission ultérieure d'une clé à long terme (typiquement la clé privée RSA/ECDSA du serveur) ne permet pas de déchiffrer les sessions passées qui auraient été interceptées et stockées.

Principe

Les clés de session sont dérivées d'un secret éphémère, généré puis détruit à chaque connexion, et non de la clé à long terme.
La clé privée du serveur ne sert plus qu'à authentifier (signature), pas à transporter le secret.
Référence : RFC 8446 (TLS 1.3).

Mécanismes dans TLS

TLS 1.2
Suites DHE ou ECDHE, ex. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Le pre-master secret est issu de l'échange Diffie-Hellman éphémère, puis les clés sont dérivées via la PRF ; les clés privées éphémères sont jetées après usage.
Les suites à échange RSA statique (TLS_RSA_WITH_AES_128_CBC_SHA) n'offrent aucune FS : le pre-master secret est chiffré avec la clé publique du serveur, donc récupérable a posteriori avec la clé privée.

TLS 1.3
L'échange de clés est (EC)DHE dans tous les modes, sauf le mode PSK seul (psk_ke).
Dérivation par HKDF à partir du secret éphémère partagé.
L'authentification du serveur se fait par la signature du message CertificateVerify (et non du ServerHello).

Argument cryptographique : connaître la clé de signature du serveur n'aide en rien à résoudre le problème DH/ECDH ; le secret partagé dépend aussi de la part éphémère du client, jamais stockée ni transmise.

Bénéfices concrets

Bénéfice Explication

Protection rétroactive Une clé privée volée (fuite, Heartbleed, saisie légale) ne déchiffre pas le trafic déjà capturé.
Cloisonnement des sessions L'attaquant doit casser chaque session séparément : coût prohibitif.
Contre « store now, decrypt later » Neutralise l'archivage massif de trafic en vue d'un déchiffrement futur.
Bonnes pratiques Recommandée par l'ANSSI (Recommandations de sécurité relatives à TLS) et le NIST (SP 800-52 Rev. 2) ; attendue par les référentiels de conformité modernes.

Limites et conditions

Suites adaptées obligatoires : désactiver RSA statique ; en TLS 1.3, éviter le mode PSK sans (EC)DHE.
0-RTT (early data) en TLS 1.3 : pas de forward secrecy. Les données 0-RTT sont protégées par une clé dérivée du PSK/ticket, donc vulnérables si ce secret est compromis (et rejouables).
Reprise de session / tickets : si les clés de chiffrement des tickets sont durables et non renouvelées, la FS est affaiblie ; il faut une rotation fréquente.
Réutilisation des parts éphémères : un serveur qui réutilise longtemps la même clé « éphémère » perd l'essentiel du bénéfice.
Paramètres faibles : groupe DH de 1024 bits cassable pour une session donnée. Utiliser X25519, secp256r1, ou DHE ≥ 2048 bits (groupes nommés RFC 7919).
Journalisation des secrets (SSLKEYLOGFILE, appliances de déchiffrement) : annule la FS.

Scénario évité
L'attaquant capture et archive un an de trafic vers example.com.
Il obtient plus tard la clé privée du serveur.
Sans FS : il déchiffre l'intégralité de l'archive.
Avec ECDHE : il ne déchiffre aucune session ; chaque secret éphémère a disparu.
Fondements formels

Modèle Canetti–Krawczyk (R. Canetti, H. Krawczyk, Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels, EUROCRYPT 2001), qui formalise la notion de FS pour les protocoles d'échange de clés.
Analyses mécanisées de TLS 1.3 avec ProVerif / Tamarin : Bhargavan et al., A Cryptographic Analysis of TLS 1.3 / Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate (2017), confirmant la FS pour les modes (EC)DHE — mais pas pour les données 0-RTT.

Vérification

openssl s_client -connect example.com:443 -servername example.com
vérifier "Cipher" (ECDHE/DHE) et "Server Temp Key" (ex. X25519, 253 bits)
Ou un test SSL Labs (rubrique Forward Secrecy).

Configuration nginx typique :
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:prime256v1;
ssl_session_tickets off; ou rotation régulière des clés de ticket

Synthèse

Propriété Avec FS ((EC)DHE) Sans FS (RSA statique)

Déchiffrement rétroactif Impossible Possible si clé privée obtenue
Coût pour l'attaquant Élevé, par session Faible, une seule clé suffit
Statut Standard actuel (TLS 1.2/1.3) Supprimé en TLS 1.3

En résumé : la forward secrecy borne dans le temps l'impact d'une compromission de clé à long terme — le passé reste protégé. Elle exige (EC)DHE, des paramètres solides, une rotation des tickets de session, l'absence de journalisation des secrets, et ne couvre pas les données 0-RTT.