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?
Les suites DHE sont les trois dernières proposées par IE. Pour se connecter en DHE, le serveur doit donc refuser *toutes* les suites RSA proposées par le client.
Ben disons que ça dépend. Je connais un logiciel de serveur SSL (que j'ai écrit moi-même avec mes petites mains) qui est configurable sur ce point : dans le réglage par défaut, il utilise l'ordre de préférence du client (il prend la première cipher suite du client qu'il puisse gérer) mais on peut aussi le configurer pour faire passer sa préférence d'abord (il prend la première de _ses_ cipher suites qui soit supportée par le client).
En revanche, ça n'a pas l'air d'être le cas d'OpenSSL.
Et si tu configure un serveur comme il faut pour préférer se connecter en DHE avec IE, il ne fera pas de RSA ce qui veut dire que certains clients ne pourront pas se connecter, un exemple typique est TinySSL, mais il y a certainement d'autres clients qui n'implémentent pas DSS ou dont le DSS est complètement buggé à force de ne jamais être utilisé.
D'un certain point de vue, si le serveur accepte de faire des connexions sans PFS, c'est que la propriété de PFS n'est pas si cruciale que ça (sinon on imposerait au serveur de ne faire que du DHE, ce qui est très faisable avec la plupart des logiciels serveurs, dont OpenSSL). On pourrait dire que, sans être cruciale, la PFS est sympathique et souhaitable, mais ça me gêne toujours un peu de parler de caractéristiques de sécurité qui soient souhaitables sans être indispensables. Je trouve que c'est un signe de mauvaise spécification. C'est comme les "degrés de confiance" qu'on peut accorder à certaines clés publique dans PGP : est-ce que ça rime vraiment à grand'chose de dire qu'on a confiance "à 70%" en une certaine clé ? À partir du moment où c'est moins de 99.99%, est-ce que le risque n'est pas de toutes façons inacceptable ?
Avec modssl/Apache, on doit pouvoir arriver à favoriser un algo qui n'est pas proposé en premier par le client, mais mettre deux certifs, un DSA pour forcer le DSA sur IE, et un RSA pour passer quand même sur les clients exotiques, je ne crois pas que c'est possible, donc tu es bloqué.
Pour avoir deux certificats distincts, il faudrait pouvoir identifier le logiciel client dès le début de la connexion, ce qui n'est pas possible en SSL brut (le ClientHello ne contient pas cette information). En HTTPS, on peut faire des choses : une connexion HTTPS vient d'une URL, URL qui est obtenue en général depuis un bout de page en HTML, et on peut faire des distinctions sur le type du browser soit avec du JavaScript côté client, soit en faisant un Redirect depuis le serveur, Redirect savamment modifié suivant le type annoncé par le client. Mais bon, dans le cas du Web, la réponse la plus simple reste de se dire qu'en faisant d'autorité du DHE avec DSS, ça passera quasiment partout (non seulement Internet Explorer et Netscape, mais aussi la kyrielle de browsers web plus ou moins open-source, qui utilisent OpenSSL).
Il y a même un argument-massue : la RFC 2246 précise que le support de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans les dents des râleurs.
Ceci étant, je comprends que ce soit pénible de ne pas avoir un plein contrôle des cipher suites acceptées et de l'ordre de préférence.
--Thomas Pornin
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
Les suites DHE sont les trois dernières proposées par IE.
Pour se connecter en DHE, le serveur doit donc refuser *toutes* les
suites RSA proposées par le client.
Ben disons que ça dépend. Je connais un logiciel de serveur SSL (que
j'ai écrit moi-même avec mes petites mains) qui est configurable sur ce
point : dans le réglage par défaut, il utilise l'ordre de préférence du
client (il prend la première cipher suite du client qu'il puisse gérer)
mais on peut aussi le configurer pour faire passer sa préférence d'abord
(il prend la première de _ses_ cipher suites qui soit supportée par le
client).
En revanche, ça n'a pas l'air d'être le cas d'OpenSSL.
Et si tu configure un serveur comme il faut pour préférer se connecter
en DHE avec IE, il ne fera pas de RSA ce qui veut dire que certains
clients ne pourront pas se connecter, un exemple typique est TinySSL,
mais il y a certainement d'autres clients qui n'implémentent pas DSS ou
dont le DSS est complètement buggé à force de ne jamais être utilisé.
D'un certain point de vue, si le serveur accepte de faire des connexions
sans PFS, c'est que la propriété de PFS n'est pas si cruciale que
ça (sinon on imposerait au serveur de ne faire que du DHE, ce qui
est très faisable avec la plupart des logiciels serveurs, dont
OpenSSL). On pourrait dire que, sans être cruciale, la PFS est
sympathique et souhaitable, mais ça me gêne toujours un peu de parler
de caractéristiques de sécurité qui soient souhaitables sans être
indispensables. Je trouve que c'est un signe de mauvaise spécification.
C'est comme les "degrés de confiance" qu'on peut accorder à certaines
clés publique dans PGP : est-ce que ça rime vraiment à grand'chose de
dire qu'on a confiance "à 70%" en une certaine clé ? À partir du moment
où c'est moins de 99.99%, est-ce que le risque n'est pas de toutes
façons inacceptable ?
Avec modssl/Apache, on doit pouvoir arriver à favoriser un algo qui
n'est pas proposé en premier par le client, mais mettre deux certifs, un
DSA pour forcer le DSA sur IE, et un RSA pour passer quand même sur les
clients exotiques, je ne crois pas que c'est possible, donc tu es bloqué.
Pour avoir deux certificats distincts, il faudrait pouvoir identifier
le logiciel client dès le début de la connexion, ce qui n'est pas
possible en SSL brut (le ClientHello ne contient pas cette information).
En HTTPS, on peut faire des choses : une connexion HTTPS vient d'une
URL, URL qui est obtenue en général depuis un bout de page en HTML,
et on peut faire des distinctions sur le type du browser soit avec du
JavaScript côté client, soit en faisant un Redirect depuis le serveur,
Redirect savamment modifié suivant le type annoncé par le client. Mais
bon, dans le cas du Web, la réponse la plus simple reste de se dire
qu'en faisant d'autorité du DHE avec DSS, ça passera quasiment partout
(non seulement Internet Explorer et Netscape, mais aussi la kyrielle de
browsers web plus ou moins open-source, qui utilisent OpenSSL).
Il y a même un argument-massue : la RFC 2246 précise que le support
de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans
les dents des râleurs.
Ceci étant, je comprends que ce soit pénible de ne pas avoir un plein
contrôle des cipher suites acceptées et de l'ordre de préférence.
Les suites DHE sont les trois dernières proposées par IE. Pour se connecter en DHE, le serveur doit donc refuser *toutes* les suites RSA proposées par le client.
Ben disons que ça dépend. Je connais un logiciel de serveur SSL (que j'ai écrit moi-même avec mes petites mains) qui est configurable sur ce point : dans le réglage par défaut, il utilise l'ordre de préférence du client (il prend la première cipher suite du client qu'il puisse gérer) mais on peut aussi le configurer pour faire passer sa préférence d'abord (il prend la première de _ses_ cipher suites qui soit supportée par le client).
En revanche, ça n'a pas l'air d'être le cas d'OpenSSL.
Et si tu configure un serveur comme il faut pour préférer se connecter en DHE avec IE, il ne fera pas de RSA ce qui veut dire que certains clients ne pourront pas se connecter, un exemple typique est TinySSL, mais il y a certainement d'autres clients qui n'implémentent pas DSS ou dont le DSS est complètement buggé à force de ne jamais être utilisé.
D'un certain point de vue, si le serveur accepte de faire des connexions sans PFS, c'est que la propriété de PFS n'est pas si cruciale que ça (sinon on imposerait au serveur de ne faire que du DHE, ce qui est très faisable avec la plupart des logiciels serveurs, dont OpenSSL). On pourrait dire que, sans être cruciale, la PFS est sympathique et souhaitable, mais ça me gêne toujours un peu de parler de caractéristiques de sécurité qui soient souhaitables sans être indispensables. Je trouve que c'est un signe de mauvaise spécification. C'est comme les "degrés de confiance" qu'on peut accorder à certaines clés publique dans PGP : est-ce que ça rime vraiment à grand'chose de dire qu'on a confiance "à 70%" en une certaine clé ? À partir du moment où c'est moins de 99.99%, est-ce que le risque n'est pas de toutes façons inacceptable ?
Avec modssl/Apache, on doit pouvoir arriver à favoriser un algo qui n'est pas proposé en premier par le client, mais mettre deux certifs, un DSA pour forcer le DSA sur IE, et un RSA pour passer quand même sur les clients exotiques, je ne crois pas que c'est possible, donc tu es bloqué.
Pour avoir deux certificats distincts, il faudrait pouvoir identifier le logiciel client dès le début de la connexion, ce qui n'est pas possible en SSL brut (le ClientHello ne contient pas cette information). En HTTPS, on peut faire des choses : une connexion HTTPS vient d'une URL, URL qui est obtenue en général depuis un bout de page en HTML, et on peut faire des distinctions sur le type du browser soit avec du JavaScript côté client, soit en faisant un Redirect depuis le serveur, Redirect savamment modifié suivant le type annoncé par le client. Mais bon, dans le cas du Web, la réponse la plus simple reste de se dire qu'en faisant d'autorité du DHE avec DSS, ça passera quasiment partout (non seulement Internet Explorer et Netscape, mais aussi la kyrielle de browsers web plus ou moins open-source, qui utilisent OpenSSL).
Il y a même un argument-massue : la RFC 2246 précise que le support de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans les dents des râleurs.
Ceci étant, je comprends que ce soit pénible de ne pas avoir un plein contrôle des cipher suites acceptées et de l'ordre de préférence.
--Thomas Pornin
pornin
According to Erwann ABALEA :
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
Microsoft, donc Internet Explorer, le supporte. Au moins depuis IE 5 (j'ai essayé).
--Thomas Pornin
According to Erwann ABALEA <erwann@abalea.com>:
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
Microsoft, donc Internet Explorer, le supporte. Au moins depuis IE 5
(j'ai essayé).
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
Microsoft, donc Internet Explorer, le supporte. Au moins depuis IE 5 (j'ai essayé).
--Thomas Pornin
Jean-Marc Desperrier
Thomas Pornin wrote:
Il y a même un argument-massue : la RFC 2246 précise que le support de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans les dents des râleurs.
En effet. Cependant ça ne sera sûrement plus vrai s'il jamais il sort une révision de cette RFC.
C'est une RFC de Janvier 1999, l'IETF imposait à l'époque le support de DSS pour garantir l'interopérabilité sans avoir à payer le brevet RSA.
Mais ce n'est plus le cas dans les RFC mises à jour depuis la fin du brevet.
Thomas Pornin wrote:
Il y a même un argument-massue : la RFC 2246 précise que le support
de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans
les dents des râleurs.
En effet. Cependant ça ne sera sûrement plus vrai s'il jamais il sort
une révision de cette RFC.
C'est une RFC de Janvier 1999, l'IETF imposait à l'époque le support de
DSS pour garantir l'interopérabilité sans avoir à payer le brevet RSA.
Mais ce n'est plus le cas dans les RFC mises à jour depuis la fin du brevet.
Il y a même un argument-massue : la RFC 2246 précise que le support de TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA est "mandatory". À envoyer dans les dents des râleurs.
En effet. Cependant ça ne sera sûrement plus vrai s'il jamais il sort une révision de cette RFC.
C'est une RFC de Janvier 1999, l'IETF imposait à l'époque le support de DSS pour garantir l'interopérabilité sans avoir à payer le brevet RSA.
Mais ce n'est plus le cas dans les RFC mises à jour depuis la fin du brevet.
