[:fr]Perfect Forward Secrecy est une fonction de protocole d’agrément de clés qui garantit que les clés de sessions ne peuvent pas être compromises dans le cas où la clé privée du serveur  l’est. En générant une clé de session unique pour chaque session que l’utilisateur initie, même la compromission d’une seule clé de session n’affectera que les données échangée lors de la session chiffrée par la clé en question. Perfect Forward Secrecy représente une étape importante dans la protection des données pendant leur transmission. Tous ceux qui utilisent SSL/TLS devraient penser à l’implémenter.

Que se passait –il avant le Perfect Forward Secrecy ?

Avant PFS, les données transmises entre un serveur et un client pouvaient être compromises si la clé privée du serveur est trouvée. Une fois l’assaillant en possession de la clé privée il peut déchiffrer la session et obtenir le pré-master secret, le master secret, ainsi que les clés de chiffrement de sessions.

Cette clé privée est à la fois utilisée pour l’authentification du serveur et pour le chiffrement du secret partagé (explications plus en bas).

Cas d’exemple :

Supposons maintenant qu’un attaquant enregistre tous les échanges entre le serveur et ses nombreux clients pendant plusieurs mois. Deux ans plus tard, le serveur est décommissionné et jeté à la benne. L’attaquant en profite pour subtiliser le disque et y trouve la clé privée du serveur. Il est désormais capable de déchiffrer toutes les communications qu’il a pu intercepter. Cela lui permet de récupérer, par exemple, des mots de passe encore valides aujourd’hui.

Rappel HTTPS :

Pour rappel, HTTPS est un simple HTTP accompagné d’une couche SSL/TLS

La couche SSL a 2 objectifs s principaux :

• Vérifier que nous parlons bien au bon serveur
• S’assurer que seul le serveur peut lire ce que l’on envoie et que nous sommes les seuls à lire ce que le serveur envoie.

Comment une connexion SSL est établie?

Une connexion SSL entre un client et un serveur est initiée par un “handshake” (à l’instar du handshake TCP : SYN / SYN+ACK/ ACK), le but étant de :

• Prouver au client qu’il parle au bon serveur (et vice versa)
• Se mettre d’accord sur l’algorithme de chiffrement qui sera utilisé pour échanger les données
• Se mettre d’accord sur les clés nécessaires pour cet algorithme

Ce handshake se passe comme suit:

• Hello : Le client envoi au serveur un message ClientHello. Ce message contient toutes les informations dont le serveur a besoin pour connecter le client via SSL (Version SSL, ID session, Liste des suites cryptographiques, etc..). Le serveur répond avec un ServerHello qui contient les mêmes infos du client, et un choix sur le type de chiffrement à partir de la liste de suites cryptographiques.

• Echange de certificat : Maintenant que le contact a été établi, le serveur doit prouver son identité au client. Il lui envoie donc son certificat SSL (qui contient différentes informations : Owner du certificat, durée de validité, clé publique, etc..). Le serveur peut aussi demander à l’utilisateur son certificat mais uniquement dans des cas spéciaux de transactions sensibles.

• Echange de clés : le chiffrement des données échangées utilise un algorithme symétrique. Le client génère une clé aléatoire (“pré-master secret”), qu’il chiffre en utilisant la clé publique du certificat du serveur et l’envoie au serveur, qui la déchiffre avec sa clé privée. Cette clé sera utilisée coté client et serveur pour générer le “master secret», à partir duquel seront générées les clés de sessions qui permettront de chiffrer les échanges.

Comment marche le Perfect Forward Secrecy ?

Pour activer PFS, le client et le serveur doivent être capable d’utiliser des suites cryptographiques qui utilisent l’algorithme DIFFIE-HELLMAN pour les échanges de clés, qui seront éphémères. Ceci veut dire que le client et le serveur devront générer un nouveau set de paramètres DIFFIE-HELLMAN pour chaque session. Ces paramètres ne peuvent être ni réutilisés ni stockés, ce qui offre donc le niveau de protection requis pour renforcer les sessions.

La clé privée du serveur n’est donc utilisée qu’à des fins d’authentification (et non de déchiffrement du pré-master secret) et le serveur et client négocient un secret partagé totalement indépendant de celle-ci, grâce aux algorithmes DIFFIE-HELLMAN.

Saâd

Consultant Sécurité

[:]