HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > Propriété de PFS dans les protocoles d'échanges de clef
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Propriété de PFS dans les protocoles d'échanges de clef  

par Franck Davy (17/10/2003)



--[ Propriété de PFS dans les protocoles d'échanges de clef ]--

Cette brève aborde la propriété de PFS, parfois rencontrée au détour d'une
option de configuration de tunnel IPSec ou SSL (mandataire dans SSH). Cette
propriété (acronyme de « Perfect Forward Secrecy ») s'applique à un protocole
d'échange de clef, lorsque « la découverte d'un secret à long terme ne
compromettra pas les clefs de session échangées lors des précédents échanges ».

Typiquement, dans le cas des protocoles SSL/TLS [1], la compromission de la
clef privée (= secret à long terme)  associée au certificat X.509 présenté par
le serveur ne permettra pas de déchiffrer les preMasterSecret (=clef de
session) transmis lors des précédentes sessions (à partir desquels sont
dérivées les différentes clefs de chiffrement, scellement etc.).

Les protocoles d'échange de clef mis en oeuvre dans HTTPS (SSL/TLS) sont donc
brièvement abordés, ainsi que les risques sous-jacents.



1. Protocoles d'échange de clef

1.1. Généralités

Lors du protocole handshake SSL/TLS, client et serveur négocient les
algorithmes qui leur permettront d'assurer les services de sécurité requis tout
au long de la session SSL/TLS, à savoir les services d'authenfication des tiers
et des données, de confidentialité et d'intégrité des données.

Pour avoir de plus amples détails sur ces différents services et les mécanismes
sur lesquels ils s'appuient, consulter le support du cours d'introduction à la
cryptographie [2].

Les paramètres négociés sont, typiquement :
- un protocole d'échange de clef... :
 · transport de clef via RSA ;
 · génération de clef par Diffie-Hellman.
- ...associé à un mécanisme d'authentification :
 · certificat X.509 authentifiant une clef publique RSA ou DSA.
- un algorithme de chiffrement ;
- une fonction de scellement :
 · fonction à sens unique (SHA, MD5) indexée par une clef (secrète), pour
 calculer un MAC.

Au niveau d'un serveur Apache la directive SSLCipherSuite de mod_ssl est
employée pour décrire les algorithmes supportés par le serveur, avec, par
défaut, la chaîne suivante :
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL,

Chaîne dont une signification humainement compréhensible pourra être obtenue
avec la commande qui suit : 
$ openssl ciphers -v 'ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL'

Cette brève s'attarde plus particulièrement sur les protocoles d'échange de
clef s'appuyant sur RSA pour l'authentification des parties -- l'immense
majorité des serveurs HTTPS employant de telles clefs publiques dans leurs
certificats. 
Les différents algorithmes et protocoles d'échange de clef ne seront pas
précisément décrits (faisant l'objet d'une abondante documentation en ligne).

Pour présenter les différents cas possibles, et notamment ceux où la propriété
de PFS existe, on considérera les « triplets » suivants (détaillés par la
suite) :
- DES-CBC3-SHA ;
- EXP-DES-CBC-SHA ;
- EXP-EDH-RSA-DES-CBC-SHA.


1.2. Triplet d'algorithmes DES-CBC3-SHA

Le détail de ce triplet est comme suit :

$ openssl ciphers -v 'DES-CBC3-SHA'
DES-CBC3-SHA  SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

L'échange de clef est réalisé par RSA. Autrement dit, la « clef de session
SSL/TLS » (par abus de langage) sera transmise du client au serveur en
s'appuyant sur l'algorithme RSA.

Plus précisément, à travers une trace réseau :

$ openssl s_client -connect 192.0.2.2:443 -cipher 'DES-CBC-SHA'

# ssldump -i eth0 port 443

New TCP connection #1: 192.0.2.1 (1390) <-> 192.0.2.2 (443)

1  0.0167 (0.0167)  C>S SSLv2 compatible client hello
  Version 3.1 
  cipher suites
  TLS_RSA_WITH_DES_CBC_SHA  

2  0.1111 (0.0943)  S>C  Handshake
      ServerHello
        Version 3.1 
        session_id[32]
	random[32]
        cipherSuite   TLS_RSA_WITH_DES_CBC_SHA
        compressionMethod    NULL

=> Négociation du triplet d'algorithmes (suite à la liste - constituée d'un seul
élément dans cet exemple - présentée par le client au serveur).

3  0.1428 (0.0002)  S>C  Handshake
      Certificate
	certificat[826]

=> Présentation par le serveur de son certificat X.509.
La clef publique RSA est extraite du certificat -- si celui-ci est correctement
validé par le navigateur.

4  0.1428 (0.0000)  S>C  Handshake
      ServerHelloDone
5  0.1756 (0.0327)  C>S  Handshake
      ClientKeyExchange
	EncryptedPreMasterSecret[128]

=> Le client génère le PreMasterSecret (« clef de session »), et chiffre ce
dernier avec la clef publique RSA extraite du certificat. 
Le résultat est transmis au serveur.

6  0.1756 (0.0000)  C>S  ChangeCipherSpec
7  0.1756 (0.0000)  C>S  Handshake
8  0.2322 (0.0566)  S>C  ChangeCipherSpec
9  0.2322 (0.0000)  S>C  Handshake

=> Fin de la négociation (handshake).
Le transfert de données chiffrées/authentifiées peut alors commencer
(message ChangeCipherSpec).

10 6.0380 (5.9057)  C>S  application_data
11 6.0380 (0.0000)  C>S  application_data
12 6.1580 (0.1200)  C>S  application_data
13 6.1580 (0.0000)  C>S  application_data
14 6.1673 (0.0092)  S>C  application_data

15 6.1779 (0.0106)  S>C  Alert
     6.1783 (0.0003)  S>C  TCP FIN
16 6.2180 (0.0396)  C>S  Alert
     6.2181 (0.0001)  C>S  TCP FIN 

=> Fin de la session SSL/TLS, et terminaison de la connexion TCP.

Dans ce mode, la clef de session est générée unilatéralement et transmise
chiffrée du client vers le serveur en utilisant la clef publique RSA du
certificat.
Toute personne possédant la clef privée associée au certificat et étant en
mesure de capturer le trafic sera capable de déchiffrer le preMasterSecret
transmis du client au serveur, et par conséquent de déchiffrer le flux.
De même, une personne ayant capturé N sessions et réussissant à obtenir la clef
privée, sera en mesure de déchiffrer ces N sessions préalablement capturées.  

=> Autrement dit, la compromission de la clef privée associée au certificat
serveur permettra de compromettre l'intégralité des sessions préalablement
négociées.

La garantie du secret sur le long terme n'est donc _pas_ garantie.

À titre d'illustration, le programme ssldump [3] muni de la clef privée du
serveur SSL/TLS sera en mesure de déchiffrer la capture DES-CBC3-SHA.pcap de la
manière suivante :

# ssldump -q -r DES-CBC3-SHA.pcap -d -k web.key -p secret

Les fichiers nécessaires sont téléchargeables aux URL :
- clef privée du serveur : http://www.hsc.fr/~davy/traces/web.key ;
- fichier de traces : http://www.hsc.fr/~davy/traces/DES-CBC3-SHA.pcap .

Remarque : l'application ssldump ne supporte pas, dans sa version actuelle,
l'algorithme de chiffrement AES. Elle ne sera donc pas en mesure de déchiffrer
une session employant cet algorithme, PFS ou non.


1.3. Triplet d'algorithmes EXP-DES-CBC-SHA

Le détail de ce triplet est comme suit :

$ openssl ciphers -v 'EXP-DES-CBC-SHA'
EXP-DES-CBC-SHA  SSLv3 Kx=RSA(512)  Au=RSA  Enc=DES(40)  Mac=SHA1 export

L'échange de clef est réalisé par RSA, cependant le client ayant proposé cet
algorithme avertit le serveur qu'il est limité dans la taille des clefs
publiques RSA qu'il sera autorisé à manipuler pour chiffrer le preMasterSecret.
Dans ce cas particulier, les lois à l'exportation hors U.S. brident le
navigateur, ne pouvant utiliser de clef RSA d'une taille supérieure à 512 bits
pour _chiffrer_ la clef de session (et, accessoirement, limitent également le
nombre de bits utiles des clefs de chiffrement à 40 bits). 
Seule solution pour une négociation concluante : demander au serveur de générer
un _nouveau_ bi-clef RSA, pour lequel la clef publique aura la taille
acceptable de 512 bits, et sera donc en mesure d'être utilisée par le client
pour chiffrer la clef de session. 

=> La clef publique du certificat servira, quant à elle, à la vérification de
la signature calculée sur la nouvelle clef publique de 512 bits.

À travers une trace (à partir du segment de données 3 uniquement) :

3 0.0302 (0.0000) S>CV3.1(836) Handshake 
	Certificate
	 certificate[826]   <------------------------------------------
                                                                       |
=> Présentation par le serveur de son certificat X.509. ---------------
La taille de la clef publique présentée excède les 512 bits autorisés.
La clef publique RSA est extraite du certificat -- si celui-ci est correctement
validé par le navigateur. Elle ne pourra cependant pas être utilisée par le
navigateur pour chiffrer le preMasterSecret à transmettre au serveur.

4 0.0304 (0.0001) S>CV3.1(205) Handshake
	ServerKeyExchange
	 params
		RSA_modulus[64]
		RSA_exponent[3]
		signature[128]

=> Dans la foulée du message précédent, le serveur transmet au client une
nouvelle clef publique RSA (caractérisée par le modulus n et l'exposant
publique e). Cette clef, générée à la volée, est signée : d'où la présence d'un
champ « signature ». Le client vérifie cette signature avec le certificat
précédent : la nouvelle clef est alors authentifiée.

5 0.0304 (0.0000) S>CV3.1(4) Handshake
	ServerHelloDone
6 0.0433 (0.0129) C>SV3.1(70) Handshake
	ClientKeyExchange
		EncryptedPreMasterSecret[64] 

=> Le client chiffre le preMasterSecret avec la clef publique RSA générée à la
volée par le serveur.

7 0.0433 (0.0000) C>SV3.1(1) ChangeCipherSpec 
8 0.0433 (0.0000) C>SV3.1(40) Handshake 
9 5.7351 (5.6917) C>SV3.1(40) application_data
[...]

Dans ce mode, la clef de session est, une fois de plus, générée unilatéralement
; néanmoins la compromission du secret à long terme (la clef privée côté
serveur) ne permettra pas de déchiffrer le preMasterSecret transmis du client
au serveur, d'où une propriété de PFS : au mieux l'attaquant pourra conduire
une attaque active sur la session courante (Man-in-the-Middle avec la clef
correspondant effectivement au certificat présenté [3]), néanmoins la sécurité
des précédentes sessions négociées sera préservée.

À titre d'illustration, le programme ssldump muni de la clef privée du serveur
ne sera pas en mesure de déchiffrer la capture EXP-DES-CBC-SHA.pcap :

# ssldump -q -r EXP-DES-CBC-SHA.pcap -d -k web.key -p secret

Les fichiers nécessaires sont téléchargeables à ces URL :
- clef privée du serveur : http://www.hsc.fr/~davy/traces/web.key ;
- fichier de traces : http://www.hsc.fr/~davy/traces/EXP-DES-CBC-SHA.pcap .


1.4. Triplet d'algorithmes EDH-RSA-DES-CBC3-SHA

Le détail de ce triplet est comme suit :

$ openssl ciphers -v 'EDH-RSA-DES-CBC3-SHA' :
EDH-RSA-DES-CBC3-SHA  SSLv3 Kx=DH  Au=RSA  Enc=3DES(168)  Mac=SHA1

L'échange de clef est, dans ce cas, réalisé par Diffie-Hellman éphémère : les
valeurs publiques Diffie-Hellman sont générées à la volée, de part et d'autre.
La valeur publique transmise par le serveur est signée : la clef publique du
certificat présenté par le serveur sert donc au client pour la vérification de
la signature.

Rmq : on comprend mieux pourquoi les extensions des certificats serveurs sont
keyEncipherment et digitalSignature : dans le premier cas, il s'agit pour le
client de chiffrer la « clef de session » avec la clef présente dans le
certificat ; dans le second, il s'agit de vérifier une signature -- sur une
valeur publique DH ou sur une clef RSA de taille acceptable pour les lois à
l'exportation.

À partir du troisième segment de données :

3 0.1048 (0.0000) S>CV3.1(836) Handshake
	Certificate
	 certificate[826]

=> Présentation par le serveur de son certificat X.509.

4 0.1049 (0.0001) S>CV3.1(397) Handshake
	ServerKeyExchange
	 params
		DH_p[128]
		DH_g[1]
		DH_Ys[128]
		signature[128]

=> Transmission des paramètres Diffie-Hellman par le serveur (modulus p,
générateur g, valeur publique Y), signés par la clef privée associée au
certificat.

5 0.1049 (0.0000) S>CV3.1(4) Handshake
	ServerHelloDone
6 0.3340 (0.2291) C>SV3.1(134) Handshake
	ClientKeyExchange
	 DiffieHellmanClientPublicValue[128]

=> Transmission de la valeur publique DH du client.

7 0.3340 (0.0000) C>SV3.1(1) ChangeCipherSpec
8 0.3340 (0.0000) C>SV3.1(40) Handshake
9 0.4104 (0.0763) S>CV3.1(1) ChangeCipherSpec
10 0.4104 (0.0000) S>CV3.1(40) Handshake

11 9.9636 (9.5532) C>SV3.1(40) application_data
[...]

Comme précédemment, le secret permanent aura uniquement servi à authentifier la
valeur publique DH transmise par le serveur. D'où la propriété de PFS.

De plus, ce type d'échange présente l'intérêt de ne pas fonctionner en mode
dégradé -- au contraire du précédent mode, contraint de manipuler des clefs RSA
de 512 bits et des clefs de chiffrement dont la taille utile est inférieure au
seuil généralement « acceptable ».

Malheureusement, l'algorithme d'échange de clef Diffie-Hellman n'est pas
supporté par toutes les implémentations SSL/TLS ; ce point sera à nouveau
abordé en conclusion.

Comme précédemment, le programme ssldump muni de la clef privée du serveur ne
sera pas en mesure de déchiffrer la capture réalisée :

# ssldump -q -r EDH-RSA-DES-CBC3-SHA.pcap -d -k web.key -p secret

Les fichiers nécessaires sont téléchargeables aux URL suivantes :
- clef privée du serveur : http://www.hsc.fr/~davy/traces/web.key ;
- fichier de traces : http://www.hsc.fr/~davy/traces/EDH-RSA-DES-CBC3-SHA.pcap .



2. Les risques - Cas des protocoles SSL/TLS.

Le risque survient évidemment lors la clef privée RSA (permanente) du serveur
SSL/TLS est compromise.

L'exemple le plus typique d'une telle compromission est celui du serveur
d'application en frontal sur internet ayant les plus grandes difficultés avec
la mise sous forme canonique des URL ; à titre d'illustration, pour un serveur
WebLogic 5.1.0 Service Pack 9, les URL suivantes (liste non exhaustive)
permettaient d'exploiter trivialement des failles de type « directory listing »
ou encore « directory traversal » qui, associées à des permissions peu
restrictives sur le système de fichiers, pouvaient permettre de télécharger la
clef privée du serveur (traditionnellement conservée en clair sur le disque) :

  https://www.domain.tld/file/
  https://www.domain.tld/%00/
  https://www.domain.tld/%2e/
  https://www.domain.tld/%2f/
  https://www.domain.tld/%5c/


Outre les failles de serveurs d'applications, les failles des applications à
proprement parler sont un des principaux vecteurs d'attaque. 

Ainsi, outre la mise à jour de tels serveurs et l'audit - en terme de sécurité,
et non de qualité de code - approfondi des applications ainsi publiées, la mise
en place d'un relais-inverse est généralement recommandée [5][6].
Relais-inverse qui, à défaut de réellement « filtrer » les paramètres passés
aux applications par GET et POST, aura la tâche primordiale d'assurer la bonne
mise sous forme canonique des URL qu'il mandatera, afin qu'un serveur
d'applications peu robuste n'affiche pas le source du fichier /index.js%70, là
où il aurait correctement interprêté l'URI /index.jsp...

En dehors de l'exploitation d'une vulnérabilité au niveau d'un serveur ou des
applications qu'il publie, de récentes publications [7][8] sur les attaques par
analyse temporelle ( « Timing-based attacks on RSA keys ») ont laissé entrevoir
la possibilité d'obtenir la clef privée d'un serveur de façon distante.
Évidemment, les conditions d'exploitation et la faisabilité d'une telle attaque
la rendent peu probable -- notamment par rapport aux exemples précédemment
cités.



3. Conclusion

Pour l'anecdote, le navigateur IE (dans sa version 6.0) propose, par défaut,
les algorithmes suivants par ordre de préférence :

  - TLS_RSA_WITH_RC4_128_MD5
  - TLS_RSA_WITH_RC4_128_SHA
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA
  - SSL2_RC4_128_WITH_MD5
  - SSL2_DES_192_EDE3_CBC_WITH_MD5
  - SSL2_RC2_CBC_128_CBC_WITH_MD5
  - TLS_RSA_WITH_DES_CBC_SHA
  - SSL2_DES_64_CBC_WITH_MD5
  - TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
  - TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
  - TLS_RSA_EXPORT_WITH_RC4_40_MD5
  - TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
  - SSL2_RC4_128_EXPORT40_WITH_MD5
  - SSL2_RC2_CBC_128_CBC_WITH_MD5
  - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  - TLS_DHE_DSS_WITH_DES_CBC_SHA
  - TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA


Le mode Diffie-Hellman éphémère (TLS_DHE_) est donc proposé en dernier lieu --
autrement dit après le protocole SSLv2, ou encore les modes dégradés favorisant
l'usage de clefs de taille plus réduite (modes EXPORT). Associé au fait que la
signature des paramètres DH publics doit être réalisée avec une clef DSA
(TLS_DHE_DSS_), on en déduit que le serveur devra, de plus, présenter un
certificat comportant une clef DSA (ce qui, en pratique, n'est pas commun) :

$ openssl s_client -cipher 'EDH-DSS-DES-CBC3-SHA' \ 
		   -connect myhosting.com:443  
CONNECTED(00000003) 31791:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:455:


$ openssl s_client -cipher 'EDH-DSS-DES-CBC-SHA' \
		   -connect myhosting.com:443                                                
CONNECTED(00000003) 31808:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:455:


Là où le comportement suivant (Apache/mod_ssl configuré par défaut) serait plus
satisfaisant :

$ openssl s_client -connect www.hsc.fr:443
CONNECTED(00000003)
[...]
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA


Accessoirement, le « IIS Certificate Wizard » ne propose pas la génération d'un
bi-clef DSA -- l'importation d'un certificat DSA est, en revanche,
envisageable.

Bien sûr, dans les modes éphémères, une plus lourde charge est imposée au
serveur au profit d'une meilleure sécurité (dans la mesure où des paramètres
supplémentaires doivent être générés à la volée). Néanmoins, ce choix devrait
être laissé à la discrétion de l'administrateur, libre au non d'accepter ce
surcoût calculatoire, en configurant explicitement la liste des triplets
proposés par son serveur ; ceci en partant du principe que le client présentera
des triplets allant du plus « fort » au plus « faible » afin d'obtenir le
meilleur compromis. Ce qui n'est pas le cas en pratique, d'après ce qui a
précédé.

La propriété de PFS n'est donc pas acquise, et non immédiate dans un extranet
faisant, par exemple, usage de passerelles « VPN SSL » (à destination d'une
population dont les navigateurs s'appuient essentiellement sur la MS CryptoAPI)
: il faudra en effet configurer ces passerelles pour accepter, en priorité, les
derniers triplets demandés par IE -- le tout avec des clefs DSA, et en
considérant une diminution certaine des performances par rapport à celles
affichées.



4. Liens

[1] « The TLS Protocol Version 1.0 »
http://www.ietf.org/rfc/rfc2246.txt

[2] « Introduction à la Cryptographie » - Ghislaine Labouret
http://www.hsc.fr/ressources/cours/crypto/index.html.fr

[3] « SSLDump home page » - Eric Rescorla
http://www.rtfm.com/ssldump/

[4] « Les attaques du singe intercepteur contre SSH et HTTPS » - Denis Ducamp
http://www.hsc.fr/ressources/presentations/mitm2002/index.html.fr

[5] « Pourquoi un relais inverse » - Denis Ducamp
 http://www.hsc.fr/ressources/breves/pourquoi-relais-inverse.html

[6] « Filtrer des URL dans un relais inverse » - Denis Ducamp
 http://www.hsc.fr/ressources/breves/filtre-relais-inverse.html

[7] « Timing-based attacks on RSA keys » - OpenSSL Security Advisory
http://www.openssl.org/news/secadv_20030317.txt

[8] « Remote timing attacks are practical » - David Brumley/Dan Boneh
 http://www.usenix.org/events/sec03/tech/brumley/brumley_html/index.html 



Dernière modification le 12 novembre 2003 à 13:55:00 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants