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?
[...] 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?
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 ...
Salus wrote:
[...] 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?
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 ...
[...] 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?
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 ...
Nicob
On Wed, 26 Nov 2003 03:06:08 -0800, Salus wrote:
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces informations?
http://www.hsc.fr/ressources/breves/pfs.html
Nicob
On Wed, 26 Nov 2003 03:06:08 -0800, Salus wrote:
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces informations?
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces informations?
http://www.hsc.fr/ressources/breves/pfs.html
Nicob
pornin
According to Jean-Marc Desperrier :
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 ...
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
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
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 ...
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.
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 ...
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
Jean-Marc Desperrier
Thomas Pornin wrote:
According to Jean-Marc Desperrier :
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 ...
Pour SSL ça dépend de ce que négocient le client et le serveur.
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 :-)
Thomas Pornin wrote:
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
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 ...
Pour SSL ça dépend de ce que négocient le client et le serveur.
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 :-)
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 ...
Pour SSL ça dépend de ce que négocient le client et le serveur.
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 :-)
pornin
According to Jean-Marc Desperrier :
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)
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
According to Jean-Marc Desperrier <jmdesp@alussinan.org>:
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)
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.
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)
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
salus1
[...]
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces informations?
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Vous le savez?
Merci ;-)
Salus
[...]
Est-ce cela le PFS? Ne pas laisser passer sur le reseau ces informations?
compressionMethod NULL.... Je ne savais pas qu'il etait possible de
demander a openSSL de compresser et je n'ai rien trouve dans les
fichiers usuels ou mentionner cela.
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Vous le savez?
Merci ;-)
Salus
pornin
According to Salus :
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Le standard SSL (aka TLS, cf RFC 2246) prévoit un système pour que le client et le serveur se mettent d'accord sur les algorithmes de cryptographie à utiliser, et aussi un algorithme de compression à appliquer sur les données. Mais il n'existe qu'un seul algorithme standard de compression (au sein de SSL/TLS), c'est "NULL", alias l'absence de compression.
Quand je regarde le code source d'OpenSSL, je vois (dans ssl/s23_srvr.c) les lignes suivantes :
/* COMPRESSION */ *(d++)=1; *(d++)=0;
c'est-à-dire que le serveur annonce qu'il connaît exactement _une_ méthode de compression, identifiée par le numéro "0", qui est le numéro standard de la méthode "NULL" (pas de compression du tout). Ce n'est pas configurable. Donc il ne doit pas y avoir moyen de convaincre OpenSSL de faire de la compression par une simple configuration.
--Thomas Pornin
According to Salus <salus1@netcourrier.com>:
compressionMethod NULL.... Je ne savais pas qu'il etait possible de
demander a openSSL de compresser et je n'ai rien trouve dans les
fichiers usuels ou mentionner cela.
Le standard SSL (aka TLS, cf RFC 2246) prévoit un système pour que
le client et le serveur se mettent d'accord sur les algorithmes de
cryptographie à utiliser, et aussi un algorithme de compression à
appliquer sur les données. Mais il n'existe qu'un seul algorithme
standard de compression (au sein de SSL/TLS), c'est "NULL", alias
l'absence de compression.
Quand je regarde le code source d'OpenSSL, je vois (dans ssl/s23_srvr.c)
les lignes suivantes :
/* COMPRESSION */
*(d++)=1;
*(d++)=0;
c'est-à-dire que le serveur annonce qu'il connaît exactement _une_
méthode de compression, identifiée par le numéro "0", qui est le numéro
standard de la méthode "NULL" (pas de compression du tout). Ce n'est pas
configurable. Donc il ne doit pas y avoir moyen de convaincre OpenSSL
de faire de la compression par une simple configuration.
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Le standard SSL (aka TLS, cf RFC 2246) prévoit un système pour que le client et le serveur se mettent d'accord sur les algorithmes de cryptographie à utiliser, et aussi un algorithme de compression à appliquer sur les données. Mais il n'existe qu'un seul algorithme standard de compression (au sein de SSL/TLS), c'est "NULL", alias l'absence de compression.
Quand je regarde le code source d'OpenSSL, je vois (dans ssl/s23_srvr.c) les lignes suivantes :
/* COMPRESSION */ *(d++)=1; *(d++)=0;
c'est-à-dire que le serveur annonce qu'il connaît exactement _une_ méthode de compression, identifiée par le numéro "0", qui est le numéro standard de la méthode "NULL" (pas de compression du tout). Ce n'est pas configurable. Donc il ne doit pas y avoir moyen de convaincre OpenSSL de faire de la compression par une simple configuration.
--Thomas Pornin
Jean-Marc Desperrier
Thomas Pornin wrote:
Je ne vois pas quel est le problème.
Pourtant, tu le décris un peu plus loin dans ton message ...
[...] Le reste concerne le serveur, qu'il faut convaincre de faire ainsi
Au fond, ça doit être là qu'on s'est mal compris. Je ne sais pas ce que tu as lu dans mon message, mais je n'ai jamais dit que c'était impossible à faire, seulement que ça n'était pas le cas le plus courant. Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut configurer le serveur de manière spéciale pour y arriver avec IE, puisqu'il faut impérativement un certificat DSS ce qui doit être le cas de 0.5% des serveurs. Erwann, si tu nous lis, tu as le chiffre ? ;-)
Dans SSL, le client envoie la liste des "cipher suites" qu'il supporte, et le serveur choisit celle qui lui convient le mieux.
Non. Enfin la majorité des serveurs ne sont pas implémentés comme cela.
[...] 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).
Tu vois, tu indique plus loin que les serveurs sont implémentés pour préférer la première suite proposée par le client, et *pas* celle qui leur convient le mieux.
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.
Alors qu'avec Mozilla, les trois premiers choix sont trois suites AES/DHE.
Donc avec IE, seul un serveur qui n'a un certificat DSS et pas de RSA se connectera en DHE, et donc fera du PFS. Alors qu'avec Mozilla, tous les serveurs supportant l'AES se connectent directement en DHE et font du PFS. Par *défaut*, *d'usine*, sans toucher aucun réglage.
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é.
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é.
Thomas Pornin wrote:
Je ne vois pas quel est le problème.
Pourtant, tu le décris un peu plus loin dans ton message ...
[...] Le reste concerne le serveur, qu'il faut convaincre
de faire ainsi
Au fond, ça doit être là qu'on s'est mal compris.
Je ne sais pas ce que tu as lu dans mon message, mais je n'ai jamais dit
que c'était impossible à faire, seulement que ça n'était pas le cas le
plus courant.
Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut
configurer le serveur de manière spéciale pour y arriver avec IE,
puisqu'il faut impérativement un certificat DSS ce qui doit être le cas
de 0.5% des serveurs.
Erwann, si tu nous lis, tu as le chiffre ? ;-)
Dans SSL, le client envoie la liste
des "cipher suites" qu'il supporte, et le serveur choisit celle qui lui
convient le mieux.
Non. Enfin la majorité des serveurs ne sont pas implémentés comme cela.
[...] 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).
Tu vois, tu indique plus loin que les serveurs sont implémentés pour
préférer la première suite proposée par le client, et *pas* celle qui
leur convient le mieux.
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.
Alors qu'avec Mozilla, les trois premiers choix sont trois suites AES/DHE.
Donc avec IE, seul un serveur qui n'a un certificat DSS et pas de RSA se
connectera en DHE, et donc fera du PFS.
Alors qu'avec Mozilla, tous les serveurs supportant l'AES se connectent
directement en DHE et font du PFS.
Par *défaut*, *d'usine*, sans toucher aucun réglage.
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é.
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é.
Pourtant, tu le décris un peu plus loin dans ton message ...
[...] Le reste concerne le serveur, qu'il faut convaincre de faire ainsi
Au fond, ça doit être là qu'on s'est mal compris. Je ne sais pas ce que tu as lu dans mon message, mais je n'ai jamais dit que c'était impossible à faire, seulement que ça n'était pas le cas le plus courant. Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut configurer le serveur de manière spéciale pour y arriver avec IE, puisqu'il faut impérativement un certificat DSS ce qui doit être le cas de 0.5% des serveurs. Erwann, si tu nous lis, tu as le chiffre ? ;-)
Dans SSL, le client envoie la liste des "cipher suites" qu'il supporte, et le serveur choisit celle qui lui convient le mieux.
Non. Enfin la majorité des serveurs ne sont pas implémentés comme cela.
[...] 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).
Tu vois, tu indique plus loin que les serveurs sont implémentés pour préférer la première suite proposée par le client, et *pas* celle qui leur convient le mieux.
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.
Alors qu'avec Mozilla, les trois premiers choix sont trois suites AES/DHE.
Donc avec IE, seul un serveur qui n'a un certificat DSS et pas de RSA se connectera en DHE, et donc fera du PFS. Alors qu'avec Mozilla, tous les serveurs supportant l'AES se connectent directement en DHE et font du PFS. Par *défaut*, *d'usine*, sans toucher aucun réglage.
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é.
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é.
Erwann ABALEA
Bonjour,
On Thu, 27 Nov 2003, Jean-Marc Desperrier wrote:
Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut configurer le serveur de manière spéciale pour y arriver avec IE, puisqu'il faut impérativement un certificat DSS ce qui doit être le cas de 0.5% des serveurs. Erwann, si tu nous lis, tu as le chiffre ? ;-)
Je lis, je lis... ;)
Chez nous, un beau 0. La plupart des clients ne savent déjà pas ce qu'est un certificat, une clé privée, et parfois même un mot de passe, alors aller faire une manip spécifique pour avoir un certificat DSS, ça ne risque pas d'arriver. Je n'irais pas mettre ma main à couper que chez VeriSign le constat sera le même, mais je le crois. (il est toujours possible qu'un techos ait fait ce genre de demande, et je n'ai pas envie de perdre une main pour ces c*nneries :)). Je pense qu'on peut aller jusqu'à 10 certificats DSS pour plusieurs centaines de milliers de certificats vendus par VeriSign et Thawte (je n'ai pas leurs chiffres, mais les CRLs peuvent être téléchargées sur le site de VeriSign, et les dernières CRL générées (cette nuit à 3h du mat') contiennent 35465 certificats au total). En comptant environ 10% de révocation, ça nous fait dans les 0.003% de certificats DSS. A la louche.
D'ailleurs, dès que j'ai un peu de temps, j'essayerais de demander un certificat DSS chez eux, tiens... Je ne suis même pas certain que la plate forme supporte une clé DSA.
[...]
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é.
Je pense qu'il doit être possible de bidouiller OpenSSL pour réaliser cela, sachant que la négociation du cryptosystème utilisé est effectuée *avant* l'authentification du serveur et du client. La liste des cryptosystèmes supportés par le client est envoyée lors du ClientHello, qui est le premier message. Le serveur répond par un ServerHello en indiquant son choix de cryptosystème parmi la liste proposée par le client, et envoit également son certificat, si le client l'a demandé lors du ClientHello.
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Il est évident que quelque chose ne va pas chez vous. Vérifiez que vous n'avez pas un trojan qui s'était introduit et qui ouvre un de vos port à un malfrat qui pompe des choses de chez vous. -+-ER in <http://neuneu.mine.nu> Se retrouver trojan comme devant-+-
Bonjour,
On Thu, 27 Nov 2003, Jean-Marc Desperrier wrote:
Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut
configurer le serveur de manière spéciale pour y arriver avec IE,
puisqu'il faut impérativement un certificat DSS ce qui doit être le cas
de 0.5% des serveurs.
Erwann, si tu nous lis, tu as le chiffre ? ;-)
Je lis, je lis... ;)
Chez nous, un beau 0. La plupart des clients ne savent déjà pas ce qu'est
un certificat, une clé privée, et parfois même un mot de passe, alors
aller faire une manip spécifique pour avoir un certificat DSS, ça ne
risque pas d'arriver. Je n'irais pas mettre ma main à couper que chez
VeriSign le constat sera le même, mais je le crois. (il est toujours
possible qu'un techos ait fait ce genre de demande, et je n'ai pas envie
de perdre une main pour ces c*nneries :)). Je pense qu'on peut aller
jusqu'à 10 certificats DSS pour plusieurs centaines de milliers de
certificats vendus par VeriSign et Thawte (je n'ai pas leurs chiffres,
mais les CRLs peuvent être téléchargées sur le site de VeriSign, et les
dernières CRL générées (cette nuit à 3h du mat') contiennent 35465
certificats au total). En comptant environ 10% de révocation, ça nous fait
dans les 0.003% de certificats DSS. A la louche.
D'ailleurs, dès que j'ai un peu de temps, j'essayerais de demander un
certificat DSS chez eux, tiens... Je ne suis même pas certain que la plate
forme supporte une clé DSA.
[...]
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é.
Je pense qu'il doit être possible de bidouiller OpenSSL pour réaliser
cela, sachant que la négociation du cryptosystème utilisé est effectuée
*avant* l'authentification du serveur et du client. La liste des
cryptosystèmes supportés par le client est envoyée lors du ClientHello,
qui est le premier message. Le serveur répond par un ServerHello en
indiquant son choix de cryptosystème parmi la liste proposée par le
client, et envoit également son certificat, si le client l'a demandé lors
du ClientHello.
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Il est évident que quelque chose ne va pas chez vous. Vérifiez que
vous n'avez pas un trojan qui s'était introduit et qui ouvre un de vos
port à un malfrat qui pompe des choses de chez vous.
-+-ER in <http://neuneu.mine.nu> Se retrouver trojan comme devant-+-
Et dans ta réponse, ce que tu fais c'est bien expliquer qu'il faut configurer le serveur de manière spéciale pour y arriver avec IE, puisqu'il faut impérativement un certificat DSS ce qui doit être le cas de 0.5% des serveurs. Erwann, si tu nous lis, tu as le chiffre ? ;-)
Je lis, je lis... ;)
Chez nous, un beau 0. La plupart des clients ne savent déjà pas ce qu'est un certificat, une clé privée, et parfois même un mot de passe, alors aller faire une manip spécifique pour avoir un certificat DSS, ça ne risque pas d'arriver. Je n'irais pas mettre ma main à couper que chez VeriSign le constat sera le même, mais je le crois. (il est toujours possible qu'un techos ait fait ce genre de demande, et je n'ai pas envie de perdre une main pour ces c*nneries :)). Je pense qu'on peut aller jusqu'à 10 certificats DSS pour plusieurs centaines de milliers de certificats vendus par VeriSign et Thawte (je n'ai pas leurs chiffres, mais les CRLs peuvent être téléchargées sur le site de VeriSign, et les dernières CRL générées (cette nuit à 3h du mat') contiennent 35465 certificats au total). En comptant environ 10% de révocation, ça nous fait dans les 0.003% de certificats DSS. A la louche.
D'ailleurs, dès que j'ai un peu de temps, j'essayerais de demander un certificat DSS chez eux, tiens... Je ne suis même pas certain que la plate forme supporte une clé DSA.
[...]
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é.
Je pense qu'il doit être possible de bidouiller OpenSSL pour réaliser cela, sachant que la négociation du cryptosystème utilisé est effectuée *avant* l'authentification du serveur et du client. La liste des cryptosystèmes supportés par le client est envoyée lors du ClientHello, qui est le premier message. Le serveur répond par un ServerHello en indiquant son choix de cryptosystème parmi la liste proposée par le client, et envoit également son certificat, si le client l'a demandé lors du ClientHello.
Mais bon. Qui fait du DHE, à part Mozilla et OpenSSL?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Il est évident que quelque chose ne va pas chez vous. Vérifiez que vous n'avez pas un trojan qui s'était introduit et qui ouvre un de vos port à un malfrat qui pompe des choses de chez vous. -+-ER in <http://neuneu.mine.nu> Se retrouver trojan comme devant-+-
Erwann ABALEA
Bonjour,
On 27 Nov 2003, Salus wrote:
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Comme l'a écrit Thomas, SSL et TLS supportent la compression, mais ne définissent aucun algo.
Il me semble qu'en tant que développeur (avec OpenSSL), on peut ajouter le support d'un schéma type "zlib" lors de la négociation SSL. Ca s'est sûrement déjà fait.
Il faut bien entendu que l'autre bout supporte le même schéma, et le déclare, sinon, ça compresse pas.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
Bonjour,
On 27 Nov 2003, Salus wrote:
compressionMethod NULL.... Je ne savais pas qu'il etait possible de
demander a openSSL de compresser et je n'ai rien trouve dans les
fichiers usuels ou mentionner cela.
Comme l'a écrit Thomas, SSL et TLS supportent la compression, mais ne
définissent aucun algo.
Il me semble qu'en tant que développeur (avec OpenSSL), on peut ajouter le
support d'un schéma type "zlib" lors de la négociation SSL. Ca s'est
sûrement déjà fait.
Il faut bien entendu que l'autre bout supporte le même schéma, et le
déclare, sinon, ça compresse pas.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Salut,
Je ne reçoit plus de messages de la mailing-list des nordistes.
-+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
compressionMethod NULL.... Je ne savais pas qu'il etait possible de demander a openSSL de compresser et je n'ai rien trouve dans les fichiers usuels ou mentionner cela.
Comme l'a écrit Thomas, SSL et TLS supportent la compression, mais ne définissent aucun algo.
Il me semble qu'en tant que développeur (avec OpenSSL), on peut ajouter le support d'un schéma type "zlib" lors de la négociation SSL. Ca s'est sûrement déjà fait.
Il faut bien entendu que l'autre bout supporte le même schéma, et le déclare, sinon, ça compresse pas.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
