Perfect Forward Secrecy
Le
salus1
Hello,
Je cherchais a mettre ne place un serveur de "blabla" sur un serveur
freeBSD.
Par hasard, je suis tombe sur SILC, un serveur permettant de discuter
mais offrant en plus une couche cryptographique au dessus.
C'est plus que parfait.
En analysant les logs, je suis tombe sur ceci:
[Wed Nov 22 10:29:53 2003] [Info] 192.168.21.123 (192.168.25.13)
security properties: aes-256-cbc hmac-sha1-96 sha1 PFS
Si je comprends bien, la liaison est securisee par l'usage symetrique
de AES-256 pour coder, les clefs publiquent ayant ete echangees avant
; integrite des donnees avec les routines SHA1 mais PFS Perfect
Forward Secrecy me dit google.com mais je n'ai rien compris du tout.
J'ai essaye de sniffer avant et apres sur le port 706/tcp avec tcpdump
pour ramener le log pour analyse avec ethereal sur mon laptop.
Constatation, je n'ai pas de paquets "en_clair" disant la version du
serveur SILC et celle du client ainsi que les aptitudes
cryptographiques des intervenants (comme je pourrais les avoir au
debut d'une liaison SSH si je venant a sniffer la transaction style
"OpenSSL version x.xx.x )
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces
informations?
Merci,
Salus
Je cherchais a mettre ne place un serveur de "blabla" sur un serveur
freeBSD.
Par hasard, je suis tombe sur SILC, un serveur permettant de discuter
mais offrant en plus une couche cryptographique au dessus.
C'est plus que parfait.
En analysant les logs, je suis tombe sur ceci:
[Wed Nov 22 10:29:53 2003] [Info] 192.168.21.123 (192.168.25.13)
security properties: aes-256-cbc hmac-sha1-96 sha1 PFS
Si je comprends bien, la liaison est securisee par l'usage symetrique
de AES-256 pour coder, les clefs publiquent ayant ete echangees avant
; integrite des donnees avec les routines SHA1 mais PFS Perfect
Forward Secrecy me dit google.com mais je n'ai rien compris du tout.
J'ai essaye de sniffer avant et apres sur le port 706/tcp avec tcpdump
pour ramener le log pour analyse avec ethereal sur mon laptop.
Constatation, je n'ai pas de paquets "en_clair" disant la version du
serveur SILC et celle du client ainsi que les aptitudes
cryptographiques des intervenants (comme je pourrais les avoir au
debut d'une liaison SSH si je venant a sniffer la transaction style
"OpenSSL version x.xx.x )
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces
informations?
Merci,
Salus
Poser une question
Non, elle passent forcément sur le réseau à un moment.
Le PFS, c'est utiliser pour l'échange des données chiffrées des clés de
session générées en utilisant un secret temporaire qui ne peut pas être
recalculé à partir des données transmises sur le réseau.
Ce secret, et les clés de session, sont détruits une fois que tu as
validé que l'échange est correct.
Quelqu'un qui aurait loggué l'échange de données, et qui arriverait par
la suite à te dérober tes clés privées ne pourrait remettre la main sur
ce secret temporaire, puisqu'il a été définitivement détruit et ne peut
pas prouver quel est le contenu de que tu as échangé (bien que s'il a
accès à tes clés privées, il a sûrement accès à ton disque dur et donc
quelquepart au contenu échangé).
A priori l'algo qui rempli le cachier des charges pour ce type d'échange
de secret, c'est DH, et les clés publiques serviront surtout à
l'authentification.
C'est bien pour la sécurité, mais le fait que SSL par exemple ne remplit
pas ce critère est très utile pour déboguer de l'extérieur une liaison ...
http://www.hsc.fr/ressources/breves/pfs.html
Nicob
Pour SSL ça dépend de ce que négocient le client et le serveur. Si la
"cipher suite" est TLS_RSA_WITH_3DES_EDE_CBC_SHA, effectivement, il
n'y a pas de PFS, et en connaissant la cli privée du certificat du
serveur, on peut déchiffrer la communication. En revanche, si on utilise
un "cipher suite" à base de "Diffie-Hellman Ephemeral" (par exemple
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA), alors l'échange de clés se fait en
Diffie-Hellman, et la clé privée du certificat du serveur ne sert que
pour de la signature ; dans ces conditions, on a la PFS.
Il est relativement rare que les serveurs SSL fassent du DHE parce que
ça augmente le coût CPU pour eux (un peu) et pour le client (beaucoup) ;
mais il faut savoir que ça existe.
--Thomas Pornin
Oui, le papier de HSC l'explique, ainsi que les difficultés pour arriver
à le configurer dans un environnement standard.
Donc généralement on tombe pas sur ce cas là avec IE (mais ça doit être
nettement plus facile avec Mozilla), et donc je n'avais jamais vu qu'il
est possible de faire échouer lamentablement un ssldump avec les bons
paramètres :-)
Je ne vois pas quel est le problème. Dans SSL, le client envoie la liste
des "cipher suites" qu'il supporte, et le serveur choisit celle qui lui
convient le mieux. Tout ce que le client a à faire, c'est supporter les
cipher suites "DHE". Le reste concerne le serveur, qu'il faut convaincre
de faire ainsi ; un moyen simple est de lui fournir un certificat DSS,
qui ne marche que pour des signatures : impossible alors pour lui de
négocier autre chose qu'une suite DHE.
Je viens d'essayer avec un serveur maison utilisant un certificat DSS.
Mozilla 1.5 annonce supporter les suites suivantes :
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
0xFEFF (un truc privé, spécifique à Mozilla)
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Internet Explorer 5.0 (annoncé comme version 5.00.3315.1000, avec support
du chiffrement en "128 bits") annonce ceci :
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
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_40_CBC_MD5
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
Dans les deux cas, ça marche sans problème, la connexion s'établit
sans problème (en TLS_DHE_DSS_WITH_AES_256_CBC_SHA avec Mozilla, et en
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA avec Internet Explorer -- mon serveur
choisit la première cipher suite qu'il supporte dans celles annoncées
par le client, car l'ordre d'annonce du client est censé être son ordre
de préférence). On notera que l'Internet Explorer n'est pas de toute
première fraîcheur, et qu'il connaît quand même des suites DHE.
--Thomas Pornin