Qu'est-ce que le Forward Secrecy (Perfect Forward Secrecy) ?

Le Forward Secrecy (aussi appele Perfect Forward Secrecy / PFS) est une propriete d’une connexion TLS qui garantit : meme si la cle privee du serveur est compromise a l’avenir, les communications chiffrees passees ne peuvent pas etre dechiffrees.

Cela fonctionne en generant une cle ephemere unique pour chaque connexion. Apres la fin de la connexion, la cle ephemere est supprimee. Personne — pas meme le proprietaire du serveur — ne peut la recreer.

Pourquoi le Forward Secrecy est important

Sans Forward Secrecy (echange de cles RSA)

L'attaquant enregistre le trafic chiffre aujourd'hui
     ↓
Des annees plus tard, l'attaquant vole la cle privee RSA du serveur
     ↓
L'attaquant dechiffre TOUT le trafic enregistre -- mots de passe, messages, tout

Avec l’echange de cles RSA statique (TLS 1.2 sans ECDHE), la meme cle privee du serveur est utilisee pour dechiffrer chaque session. Si cette cle est un jour volee, chaque conversation passee est exposee.

Avec Forward Secrecy (echange de cles ECDHE)

L'attaquant enregistre le trafic chiffre aujourd'hui
     ↓
Des annees plus tard, l'attaquant vole la cle privee du serveur
     ↓
Ne peut pas dechiffrer le trafic passe -- chaque session a utilise une cle ephemere
unique qui a ete supprimee apres la fin de la session

Chaque connexion genere une paire de cles Diffie-Hellman fraiche, calcule une cle de session unique et detruit la cle ephemere une fois terminee. La cle privee a long terme du serveur n’est utilisee que pour l’authentification (prouver l’identite), pas pour l’echange de cles (deriver la cle de chiffrement).

Comment cela fonctionne techniquement

1. Le client et le serveur generent chacun une paire de cles ECDHE ephemere (aleatoire, par connexion)
2. Ils echangent les moities publiques de ces cles ephemeres
3. Les deux calculent le meme secret partage en utilisant leur propre cle ephemere privee + la cle ephemere publique de l’autre (c’est les mathematiques de Diffie-Hellman)
4. Le secret partage derive la cle de session utilisee pour le chiffrement AES
5. Les cles ephemeres sont supprimees apres la derivation de la cle de session

La cle privee du certificat du serveur n’est utilisee que pour signer les messages du handshake — prouvant que le serveur est authentique. Elle n’est jamais utilisee pour dechiffrer le trafic.

Forward Secrecy dans les versions TLS

TLS 1.3 a resolu cela en supprimant l’echange de cles RSA — toutes les connexions TLS 1.3 ont le Forward Secrecy par defaut. Aucune configuration necessaire.

Comment verifier si votre serveur a le Forward Secrecy

# Verifier quel echange de cles votre serveur utilise
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "Server Temp Key|Protocol"

Cherchez :

• Server Temp Key: ECDH, P-256 → ✅ Forward Secrecy (ECDHE)
• Server Temp Key: X25519 → ✅ Forward Secrecy
• Pas de ligne Server Temp Key → ❌ Echange de cles RSA, pas de Forward Secrecy

Assurer le Forward Secrecy dans TLS 1.2

Nginx :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers off;

Toutes les cipher suites commencent par ECDHE — echange de cles ephemere.

Apache :

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

Pertinence dans le monde reel

Le Forward Secrecy protege contre :

• La surveillance etatique — les gouvernements enregistrant le trafic chiffre maintenant, esperant le dechiffrer plus tard lorsqu’ils acquerront les cles (par ordonnance judiciaire, piratage ou informatique quantique)
• La compromission du serveur — si un attaquant vole la cle privee de votre serveur, il peut seulement usurper l’identite du serveur a l’avenir, pas dechiffrer le trafic passe
• Les fuites de cles — exposition accidentelle de cles privees (par ex., commitees dans Git, incluses dans une sauvegarde)

C’est pourquoi Let’s Encrypt recommande les certificats ECDSA — ils s’associent naturellement avec l’echange de cles ECDHE pour un handshake entierement base sur les courbes elliptiques.

Questions frequemment posees

Mon certificat SSL doit-il supporter le Forward Secrecy ?

Le certificat lui-meme ne determine pas le Forward Secrecy — c’est la cipher suite qui le fait. Tout certificat (RSA ou ECDSA) fonctionne avec l’echange de cles ECDHE. Mais les certificats ECDSA s’associent plus naturellement avec ECDHE (les deux utilisent les courbes elliptiques), ce qui resulte en un handshake plus rapide.

Le Forward Secrecy est-il active par defaut ?

Dans TLS 1.3 : toujours — c’est obligatoire. Dans TLS 1.2 : cela depend de la configuration de votre serveur. Les configurations modernes par defaut (Nginx, Apache) privilegient les cipher suites ECDHE, mais les configurations plus anciennes pourraient encore autoriser l’echange de cles RSA.

Le Forward Secrecy ralentit-il les choses ?

De facon negligeable. L’echange de cles ECDHE ajoute ~1 ms au handshake sur du materiel moderne. L’avantage en securite depasse largement le cout.

Qu’en est-il du mode 0-RTT dans TLS 1.3 ?

Le 0-RTT (zero round trip resumption) est un cas particulier. Les donnees precoces envoyees en 0-RTT n’ont pas de Forward Secrecy contre une compromission du serveur (le PSK utilise pour la reprise est derive des cles de la session precedente). C’est pourquoi le 0-RTT ne devrait etre utilise que pour des requetes sures et idempotentes.