les 5 minutes du professeur Audenard – épisode 17 : le Perfect Forward Secrecy

Pour consulter la vidéo sur Dailymotion cliquez ici

Suite à la faille OpenSSL HeartBleed les clefs privées RSA des serveurs SSL vulnérables ont pu être volées. Seuls les serveurs configurés pour supporter le PFS (Perfect Forward Secrecy) – en français « confidentialité persistante » étaient naturellement en capacité de minimiser l’impact sur les échanges et communications passées. Pour les autres, c’est l’ensemble des communications passées qui peuvent être déchiffrées si elles ont été enregistrées... les impacts sur la confidentialité sont donc potentiellement plus importants.

PFS (Perfect Forward Secrecy) est un mécanisme dont le fonctionnement est assez méconnu et qui reste donc encore largement sous-utilisé. Cet épisode de la série des 5 minutes du Professeur Audenard vous explique ce qu’il faut retenir sur le PFS, ses principes de fonctionnement, pourquoi il renforce la sécurité des communications.

le PFS ce n’est pas compliqué

Pour comprendre le PFS (Perfect Forward Secrecy), il faut partir du moment où la clef privée d’un serveur a été compromise (intrusion, réquisition légale, fuite via faille HeartBleed, négligence d’un administrateur, …).

• Avec le PFS, seules les communications futures ou « à venir » (« devant » dans le temps – d’où le « forward » de Perfect Forward Secrecy) pourront être compromisses (notamment via une attaque de Man-in-the-Middle – « attaque de l’homme du milieu »).
• Sans le PFS, ce sont non-seulement les communications à venir qui pourront être compromises (via du MitM) mais c’est surtout toutes les communications passées/anciennes qui pourront être déchiffrées…

La propriété de PFS permet donc de protéger la sécurité des communications contre les écoutes à postériori d’une compromission des clefs SSL d’un serveur. Comment ? Le principe est que la clef de session ; qui est utilisée pour chiffrer les communications ; ne soit plus envoyée sur le réseau que ce soit chiffrée ou pas !

Important : PFS (Perfect Forward Secrecy) reste une propriété. PFS n’est ni un protocole ni un algorithme. C’est en utilisant le « bon mix » d’algorithmes (et de logiciels) que l’on obtient cette propriété de PFS.

en mode standard, la clef de session est transmise chiffrée

Les communications entre un client et un serveur web SSL sont  chiffrées via un algorithme à clefs symétriques (AES, 3DES, RC4, …). C’est donc la même clef qui est utilisée pour chiffrer et déchiffrer les communications. Cette clef doit être connue par le client et le serveur.

Lors de l’établissement d’une connexion SSL « classique », la clef partagée utilisée pour chiffrer les données est transmise entre le client et le serveur. Cette clef partagée est transférée de façon sécurisée via l’utilisation d’un chiffrement à clefs asymétriques (et plus précisément la partie publique de la clef RSA du serveur web – clef présente dans le certificat SSL que celui-ci transmet au client).

Celui qui possède partie privée de la clef RSA du serveur SSL est donc en mesure d’accéder à la clef de session utilisée pour chiffrer les communications.

Avec cette façon de transmettre la clef de session (une partie pour être exact), la propriété de PFS n’est pas obtenue.

DH, DHE et ECDHE

Au lieu de transmettre la clef de session et de chiffrer celle-ci en utilisant la partie publique de la clef RSA du serveur SSL, les algorithmes de la famille DH (Diffie-Hellman) permettent au client et au serveur de négocier une clef sans que celle-ci ne soit JAMAIS transmise sur le réseau.

Pour obtenir la propriété de PFS, il faut utiliser les variantes DHE (Diffie-Hellman Ephemeral) ou la variante ECDHE (Elliptic Curve Diffie-Hellman). En effet, dans le cadre du Diffie-Hellman « simple » (DH) les paramètres de calcul de la clef de session entre le client et le serveur sont les mêmes à chaque session (on obtient uniquement du « Forward Secrecy »). La variante ECDHE est donnée pour être nettement plus performante que DHE.

Le seul «problème» avec ces algorithmes DH, DHE ou ECDHE c’est qu’ils sont sujets aux attaques de « Man-In-the-Middle », c’est pourquoi le certificat SSL du serveur SSL reste utile afin que le client puisse vérifier qu’il est bien en contact avec le bon serveur et pas un usurpateur lors de la phase de négociation de la clef via DH, DHE ou ECDHE.

Pour revenir sur le volet des performances, l’utilisation d’ECDHE est sensiblement le même que d’utiliser un chiffrement de la clef de session avec la partie publique de la clef RSA.  Donc pour « à-peu-près le même prix » en termes de puissance de calcul, ECDHE est plus sécurisé car son utilisation offre la propriété de PFS (Perfect Forward Secrecy).

les certificats SSL restent nécessaires

Rappelons un point essentiel pour être bien clair. Les certificats SSL des serveurs restent nécessaires car ils permettent à un client d’authentifier un serveur SSL. Une fois le serveur authentifié, le client va donc négocier une clef de session via un DHE ou ECDHE (sans jamais la transmettre sur le réseau, ni en clair et ni sous forme chiffrée).

Le  certificat SSL reste donc essentiel car il s’agit ici de négocier une clef avec le bon serveur et pas un usurpateur. Ce qui change avec DHE ou ECDHE c’est donc que la partie publique de la clef RSA du serveur SSL (présente dans le certificat) est uniquement utilisée pour authentifier le serveur et qu’elle n’est plus utilisée pour échanger la clef de session.

ce qu’il faut retenir

En utilisant un algorithme de négociation de clef comme  DHE ou ECDHE, on obtient la propriété de Perfect Forward Secrecy (PFS). La clef de session utilisée pour chiffrer les communications d’étant jamais transmise sur le réseau.

Le certificat du serveur SSL reste nécessaire car il permet au client d’authentifier le serveur avec qui il négocie la clef de session (protection contre les attaques en MitM). La clef publique présente dans le certificat n’est donc PLUS utilisée pour chiffrer la clef de session.
Grâce à la propriété de PFS ; si la clef privée du serveur web venait à être compromise ;  celle-ci ne serait d’aucune utilité pour déchiffrer les anciennes communications. En revanche cette clef privée pourrait être utilisée pour monter des attaques en Man-In-the-Middle (MitM).

La propriété de PFS permet de protéger la confidentialité des communications passées contre les écoutes passives si la clef privée du serveur web venait à être compromise.

le mot de la fin

Pour un serveur web, activer le PFS (ou plus exactement utiliser DHE ou ECDHE pour négocier la clef de session) c’est protéger ses communications d’attaques à postériori.

En cas de compromission de la clef privée, seul les attaques en Man-In-the-Middle sont à considérer et aucunement celles basées sur l’écoute et l’enregistrement du trafic réseau pour une analyse et un déchiffrement à postériori.

PFS reste encore quelque chose de méconnu, et ce même pour des personnes expérimentées dans le domaine de la sécurité. Le « support » de PFS au niveau du serveur SSL reste une condition nécessaire mais elle n’est pas suffisante : il est aussi nécessaire que le client (ex : le navigateur Internet) supporte aussi le PFS.

Vous aurez compris que PFS n’est qu’une propriété et qu’en fait tout repose sur les algorithmes comme DHE ou sa variante ECDHE.

Jean-François (Jeff) Audenard

Notes : j’ai fait un petit raccourci sur la clef de session transmise entre le client et le serveur. Ce n’est qu’une partie de la clef qui est transmise et pas sa totalité, cela n’ayant pas d’importance pour ce qui concerne le PFS.