Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur
pseudo-aléatoire qui était présente jusqu'à hier dans les versions
debianisées d'openssl ?
Notament, à quel points les clés produites étaient-elles prédictibles ?
A-t-on une estimation de la diminution d'entropie du générateur et est-elle
suffisante pour autoriser des attaques par force brute ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
A. Caspis
mpg wrote:
Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur pseudo-aléatoire qui était présente jusqu'à hier dans les versions debianisées d'openssl ?
D'après ce qu'on peut lire un peu partout, Debian aurait ajouté à OpenSSL ce patch qui a pour effet de réduire l'entropie du générateur pseudo-aléatoire:
Notament, à quel points les clés produites étaient-elles prédictibles ?
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the generated keys comes from the PID of the process. This is 16 bits, typically much less effective entropy.
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir des hash des clés concernées - ils doivent bien venir de quelque part...
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006 doivent bien rigoler.
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes ont pris pour limiter les dégâts dans leur infrastructure: http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
AC
mpg wrote:
Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur
pseudo-aléatoire qui était présente jusqu'à hier dans les versions
debianisées d'openssl ?
D'après ce qu'on peut lire un peu partout, Debian aurait ajouté à
OpenSSL ce patch qui a pour effet de réduire l'entropie du générateur
pseudo-aléatoire:
Notament, à quel points les clés produites étaient-elles prédictibles ?
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the
generated keys comes from the PID of the process. This is 16 bits,
typically much less effective entropy.
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir
des hash des clés concernées - ils doivent bien venir de quelque part...
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient
pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006
doivent bien rigoler.
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes
ont pris pour limiter les dégâts dans leur infrastructure:
http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
Savez-vous où l'on peut trouver plus d'infos sur la faiblesse du générateur pseudo-aléatoire qui était présente jusqu'à hier dans les versions debianisées d'openssl ?
D'après ce qu'on peut lire un peu partout, Debian aurait ajouté à OpenSSL ce patch qui a pour effet de réduire l'entropie du générateur pseudo-aléatoire:
Notament, à quel points les clés produites étaient-elles prédictibles ?
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the generated keys comes from the PID of the process. This is 16 bits, typically much less effective entropy.
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir des hash des clés concernées - ils doivent bien venir de quelque part...
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006 doivent bien rigoler.
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes ont pris pour limiter les dégâts dans leur infrastructure: http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
AC
Al
p'tain,
la première fois que j'ai vraiment les pétoches... dans les jours qui viennent des filou vont scanner tout les points d'entrée SSH des machines de prod de divers services hébergés sur du debian... et si l'upgrade n'a pas été fait et les clés regénérées...
même ma petite soeur munie d'un script pourrait accéder à des SSH connus.
8((( le type même de "class break"
p'tain,
la première fois que j'ai vraiment les pétoches...
dans les jours qui viennent des filou vont scanner tout les points
d'entrée SSH des machines de prod de divers services hébergés sur du
debian... et si l'upgrade n'a pas été fait et les clés regénérées...
même ma petite soeur munie d'un script pourrait accéder à des SSH connus.
la première fois que j'ai vraiment les pétoches... dans les jours qui viennent des filou vont scanner tout les points d'entrée SSH des machines de prod de divers services hébergés sur du debian... et si l'upgrade n'a pas été fait et les clés regénérées...
même ma petite soeur munie d'un script pourrait accéder à des SSH connus.
8((( le type même de "class break"
mpg
Le (on) mercredi 14 mai 2008 21:03, A. Caspis a écrit (wrote) :
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the generated keys comes from the PID of the process. This is 16 bits, typically much less effective entropy.
Wouch ! Ça fait très mal en effet. Merci pour le lien, j'avais pourtant
survolé cette page du wiki mais n'avais vu que les infos utilisateur (quoi et comment mettre à jour)...
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir des hash des clés concernées - ils doivent bien venir de quelque part...
Et visiblement il y en a environ 250 000, toutes tailles de clés confondues,
ce qui est bien peu.
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006 doivent bien rigoler.
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes ont pris pour limiter les dégâts dans leur infrastructure: http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
Yep, c'est en fait pas ce biais que j'ai appris le truc (puis par un cron
qui m'a dit que des mises à jour étaient en attente sur ma machine etch). J'étais un peu surpris par l'ampleur des mesures et me demandais si c'était un excès de prudence ou si la faille était vraiment si terrible. Visiblement, c'était le 2 :-(
Manuel.
Le (on) mercredi 14 mai 2008 21:03, A. Caspis a écrit (wrote) :
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the
generated keys comes from the PID of the process. This is 16 bits,
typically much less effective entropy.
Wouch ! Ça fait très mal en effet. Merci pour le lien, j'avais pourtant
survolé cette page du wiki mais n'avais vu que les infos utilisateur (quoi
et comment mettre à jour)...
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir
des hash des clés concernées - ils doivent bien venir de quelque part...
Et visiblement il y en a environ 250 000, toutes tailles de clés confondues,
ce qui est bien peu.
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient
pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006
doivent bien rigoler.
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes
ont pris pour limiter les dégâts dans leur infrastructure:
http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
Yep, c'est en fait pas ce biais que j'ai appris le truc (puis par un cron
qui m'a dit que des mises à jour étaient en attente sur ma machine etch).
J'étais un peu surpris par l'ampleur des mesures et me demandais si c'était
un excès de prudence ou si la faille était vraiment si terrible.
Visiblement, c'était le 2 :-(
Le (on) mercredi 14 mai 2008 21:03, A. Caspis a écrit (wrote) :
D'après http://wiki.debian.org/SSLkeys :
It looks likely that the only remaining source of entropy in the generated keys comes from the PID of the process. This is 16 bits, typically much less effective entropy.
Wouch ! Ça fait très mal en effet. Merci pour le lien, j'avais pourtant
survolé cette page du wiki mais n'avais vu que les infos utilisateur (quoi et comment mettre à jour)...
Par ailleurs le script Perl mentionné dans votre lien a l'air de contenir des hash des clés concernées - ils doivent bien venir de quelque part...
Et visiblement il y en a environ 250 000, toutes tailles de clés confondues,
ce qui est bien peu.
Si tout ça est vrai, c'est dramatique, et les organisations qui auraient pris la peine d'archiver du trafic chiffré intercepté depuis mai 2006 doivent bien rigoler.
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Voir par exemple les mesures drastiques que les gens de Debian eux-mêmes ont pris pour limiter les dégâts dans leur infrastructure: http://lists.debian.org/debian-devel-announce/2008/05/msg00003.html
Yep, c'est en fait pas ce biais que j'ai appris le truc (puis par un cron
qui m'a dit que des mises à jour étaient en attente sur ma machine etch). J'étais un peu surpris par l'ampleur des mesures et me demandais si c'était un excès de prudence ou si la faille était vraiment si terrible. Visiblement, c'était le 2 :-(
Manuel.
A. Caspis
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key, and sends the result to the server. Only the server can decrypt it (with its private key): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data.
Si la clé privée du serveur est faible, le nombre aléatoire en question ("premaster secret") n'est plus secret.
Même si il y a du Diffie-Hellman derrière, dans le cas où le serveur a un PRNG faible, un attaquant peut potentiellement récupérer le g^a envoyé par le client et calculer (g^a)^b en énumérant b.
Il y a aussi le scénario où le client *et* le serveur ont des PRNG faibles. Dans ce cas l'attaquant peut potentiellement trouver la clé de session, même si la clé privée a été générée sur une machine non affaiblie (par exemple avant 2006).
Espérons que les experts confirmeront ou infirmeront bientôt (mais en ce moment ils doivent être tous occupés à colmater les brèches).
AC
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
In order to generate the session keys used for the secure connection,
the client encrypts a random number with the server's public key,
and sends the result to the server. Only the server can decrypt it
(with its private key): this is the one fact that makes the keys
hidden from third parties, since only the server and the client have
access to this data.
Si la clé privée du serveur est faible, le nombre aléatoire en question
("premaster secret") n'est plus secret.
Même si il y a du Diffie-Hellman derrière, dans le cas où le serveur
a un PRNG faible, un attaquant peut potentiellement récupérer le g^a
envoyé par le client et calculer (g^a)^b en énumérant b.
Il y a aussi le scénario où le client *et* le serveur ont des PRNG
faibles. Dans ce cas l'attaquant peut potentiellement trouver la clé
de session, même si la clé privée a été générée sur une machine non
affaiblie (par exemple avant 2006).
Espérons que les experts confirmeront ou infirmeront bientôt (mais en
ce moment ils doivent être tous occupés à colmater les brèches).
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key, and sends the result to the server. Only the server can decrypt it (with its private key): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data.
Si la clé privée du serveur est faible, le nombre aléatoire en question ("premaster secret") n'est plus secret.
Même si il y a du Diffie-Hellman derrière, dans le cas où le serveur a un PRNG faible, un attaquant peut potentiellement récupérer le g^a envoyé par le client et calculer (g^a)^b en énumérant b.
Il y a aussi le scénario où le client *et* le serveur ont des PRNG faibles. Dans ce cas l'attaquant peut potentiellement trouver la clé de session, même si la clé privée a été générée sur une machine non affaiblie (par exemple avant 2006).
Espérons que les experts confirmeront ou infirmeront bientôt (mais en ce moment ils doivent être tous occupés à colmater les brèches).
AC
Erwan David
"A. Caspis" écrivait :
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils openssl ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
"A. Caspis" <a_caspis@yahoo.com> écrivait :
mpg wrote:
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des
clés asymétriques : est-ce que les clés de sessions (symétriques) sont
touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît
la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils
openssl ?
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Euh, je connais pas très bien SSL, mais les annonces parlaient beaucoup des clés asymétriques : est-ce que les clés de sessions (symétriques) sont touchées aussi ? Ou bien est-ce qu'on peut les récupérer dès qu'on connaît la clé privée de chacun des interlocuteurs ?
Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils openssl ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Jean-Marc Desperrier
A. Caspis wrote:
[...] Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible. [...]
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
Pour SSH, c'est une référence au risque que sans certificat son mot de passe soit capturé en plus de déchiffrer la session ?
J'espère en tout cas que cet énorme plantage puisse avoir en conséquence un changement de philosophie sur la manière dont les dév Debian introduise des patch sur les logiciels dans leur distrib, qu'ils se donnent la peine de faire des vrais retours upstream, et qu'ils développent quelques réflexes d'évaluation de la sensibilité du patch (je m'apprète à patcher le *générateur* *aléatoire* d'une librairie crypto, est-ce que c'est sensible, est-ce que j'ai intérêt de m'entourer du *maximum* du précaution ? Est-ce que j'ai bien mentionné en en parlant que je suis développeur Debian, que le changement va se retrouver dans la package standard et qu'il ne s'agit pas juste de déboguer mon appli à la maison ? J'ai mis juste 1 ligne de contexte, par exemple chez Mozilla ils ont standardisé le fait d'en mettre 10, c'est juste pour s'amuser à alourdir les patch ou bien ça servirait à quelquechose des fois ?)
A. Caspis wrote:
[...]
Le scénario qui m'inquiète est celui où un client sans certificat
s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible.
[...]
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)
Pour SSH, c'est une référence au risque que sans certificat son mot de
passe soit capturé en plus de déchiffrer la session ?
J'espère en tout cas que cet énorme plantage puisse avoir en conséquence
un changement de philosophie sur la manière dont les dév Debian
introduise des patch sur les logiciels dans leur distrib, qu'ils se
donnent la peine de faire des vrais retours upstream, et qu'ils
développent quelques réflexes d'évaluation de la sensibilité du patch
(je m'apprète à patcher le *générateur* *aléatoire* d'une librairie
crypto, est-ce que c'est sensible, est-ce que j'ai intérêt de m'entourer
du *maximum* du précaution ? Est-ce que j'ai bien mentionné en en
parlant que je suis développeur Debian, que le changement va se
retrouver dans la package standard et qu'il ne s'agit pas juste de
déboguer mon appli à la maison ? J'ai mis juste 1 ligne de contexte, par
exemple chez Mozilla ils ont standardisé le fait d'en mettre 10, c'est
juste pour s'amuser à alourdir les patch ou bien ça servirait à
quelquechose des fois ?)
[...] Le scénario qui m'inquiète est celui où un client sans certificat s'est connecté depuis 2006 à un serveur SSH ou HTTPS à clé faible. [...]
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
Pour SSH, c'est une référence au risque que sans certificat son mot de passe soit capturé en plus de déchiffrer la session ?
J'espère en tout cas que cet énorme plantage puisse avoir en conséquence un changement de philosophie sur la manière dont les dév Debian introduise des patch sur les logiciels dans leur distrib, qu'ils se donnent la peine de faire des vrais retours upstream, et qu'ils développent quelques réflexes d'évaluation de la sensibilité du patch (je m'apprète à patcher le *générateur* *aléatoire* d'une librairie crypto, est-ce que c'est sensible, est-ce que j'ai intérêt de m'entourer du *maximum* du précaution ? Est-ce que j'ai bien mentionné en en parlant que je suis développeur Debian, que le changement va se retrouver dans la package standard et qu'il ne s'agit pas juste de déboguer mon appli à la maison ? J'ai mis juste 1 ligne de contexte, par exemple chez Mozilla ils ont standardisé le fait d'en mettre 10, c'est juste pour s'amuser à alourdir les patch ou bien ça servirait à quelquechose des fois ?)
A. Caspis
Jean-Marc Desperrier wrote:
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
Même si les deux participants supportent DH/AES256, n'y a t-il pas un risque si le PRNG qui génère un des deux exposants DH est faible ? (CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Pour SSH, c'est une référence au risque que sans certificat son mot de passe soit capturé en plus de déchiffrer la session ?
Pour SSH comme pour HTTPS, je m'intéressais aux conséquences de cette affaire pour les gens qui comme moi ne travaillent pas sous Debian mais peuvent être amenés à se connecter à des machines affectées.
En plus du déchiffrement a posteriori que l'on ne peut pas empêcher, il faudra en effet changer ses mots de passe sur les serveurs SSH et sites web concernés, pour éviter des attaques futures. Et peut-être charger une CRL de 262144 entrées dans son navigateur :)
AC
Jean-Marc Desperrier wrote:
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)
Même si les deux participants supportent DH/AES256, n'y a t-il pas un
risque si le PRNG qui génère un des deux exposants DH est faible ?
(CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Pour SSH, c'est une référence au risque que sans certificat son mot de
passe soit capturé en plus de déchiffrer la session ?
Pour SSH comme pour HTTPS, je m'intéressais aux conséquences de cette
affaire pour les gens qui comme moi ne travaillent pas sous Debian
mais peuvent être amenés à se connecter à des machines affectées.
En plus du déchiffrement a posteriori que l'on ne peut pas empêcher,
il faudra en effet changer ses mots de passe sur les serveurs SSH et
sites web concernés, pour éviter des attaques futures.
Et peut-être charger une CRL de 262144 entrées dans son navigateur :)
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
Même si les deux participants supportent DH/AES256, n'y a t-il pas un risque si le PRNG qui génère un des deux exposants DH est faible ? (CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Pour SSH, c'est une référence au risque que sans certificat son mot de passe soit capturé en plus de déchiffrer la session ?
Pour SSH comme pour HTTPS, je m'intéressais aux conséquences de cette affaire pour les gens qui comme moi ne travaillent pas sous Debian mais peuvent être amenés à se connecter à des machines affectées.
En plus du déchiffrement a posteriori que l'on ne peut pas empêcher, il faudra en effet changer ses mots de passe sur les serveurs SSH et sites web concernés, pour éviter des attaques futures. Et peut-être charger une CRL de 262144 entrées dans son navigateur :)
AC
Jean-Marc Desperrier
A. Caspis wrote:
[...] Même si les deux participants supportent DH/AES256, n'y a t-il pas un risque si le PRNG qui génère un des deux exposants DH est faible ? (CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Oui désolé, je n'avais pas bien lu cette partie. On connait le "g^b mod p" envoyé par le serveur ; si le nombre de valeurs pour b est suffisament faible pour les énumérer et refaire ce calcul pour toutes, on peut retrouver laquelle a été utilisée et casser le dh.
Il y a une mitigation pour un serveur par rapport à la génération de clé car on ne vient pas de le lancer immédiatement avant de lui demander cette valeur, mais bon :-( Il semble le plus probable que cela ne fasse qu'augmenter un peu le temps de calcul avant de trouver le bon b en obligeant pour chaque état initial possible du générateur aléatoire à prendre en compte les quelques dizaines, ou centaines de valeurs suivantes qui vont être générées.
A. Caspis wrote:
[...]
Même si les deux participants supportent DH/AES256, n'y a t-il pas un
risque si le PRNG qui génère un des deux exposants DH est faible ?
(CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Oui désolé, je n'avais pas bien lu cette partie. On connait le "g^b mod
p" envoyé par le serveur ; si le nombre de valeurs pour b est
suffisament faible pour les énumérer et refaire ce calcul pour toutes,
on peut retrouver laquelle a été utilisée et casser le dh.
Il y a une mitigation pour un serveur par rapport à la génération de clé
car on ne vient pas de le lancer immédiatement avant de lui demander
cette valeur, mais bon :-( Il semble le plus probable que cela ne fasse
qu'augmenter un peu le temps de calcul avant de trouver le bon b en
obligeant pour chaque état initial possible du générateur aléatoire à
prendre en compte les quelques dizaines, ou centaines de valeurs
suivantes qui vont être générées.
[...] Même si les deux participants supportent DH/AES256, n'y a t-il pas un risque si le PRNG qui génère un des deux exposants DH est faible ? (CF l'attaque suggérée plus bas dans le message auquel vous répondiez)
Oui désolé, je n'avais pas bien lu cette partie. On connait le "g^b mod p" envoyé par le serveur ; si le nombre de valeurs pour b est suffisament faible pour les énumérer et refaire ce calcul pour toutes, on peut retrouver laquelle a été utilisée et casser le dh.
Il y a une mitigation pour un serveur par rapport à la génération de clé car on ne vient pas de le lancer immédiatement avant de lui demander cette valeur, mais bon :-( Il semble le plus probable que cela ne fasse qu'augmenter un peu le temps de calcul avant de trouver le bon b en obligeant pour chaque état initial possible du générateur aléatoire à prendre en compte les quelques dizaines, ou centaines de valeurs suivantes qui vont être générées.
Al
A. Caspis wrote:
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
le gros risque c'est que la clé de session soit faible.
je ne sais pas si le générateur aléatoire en cause est utilisé pour la clé de session
SSL, comme les autres protocoles hybrides, est dépendant de la faiblesse de la crypto publique, et de la crypto privée... si l'un des 2 est faible, tout saute.
ainsi si la clé de session est faible, pas besoin de déchiffrer le RSA ou le DH, il suffit de déchiffrer le DES ou l'AES avec quelques milliers de clés non aléatoires.
donc, si quelqu'un a mémorisé des flux SSL, il pourra les déchiffrer
A. Caspis wrote:
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce
qui change vraiment quelquechose, c'est que si un protocole DH est
utilisé, le chiffrement sera de qualité sauf si le serveur ET le client
ont un chiffrement faible. Firefox avec un apache va utiliser du
DH/AES256 par défaut, pas IE)
le gros risque c'est que la clé de session soit faible.
je ne sais pas si le générateur aléatoire en cause est utilisé pour la
clé de session
SSL, comme les autres protocoles hybrides, est dépendant de la faiblesse
de la crypto publique, et de la crypto privée... si l'un des 2 est
faible, tout saute.
ainsi si la clé de session est faible, pas besoin de déchiffrer le RSA
ou le DH, il suffit de déchiffrer le DES ou l'AES avec quelques milliers
de clés non aléatoires.
donc, si quelqu'un a mémorisé des flux SSL, il pourra les déchiffrer
Pour HTTPS le fait que le client ait un certificat ne change rien (Ce qui change vraiment quelquechose, c'est que si un protocole DH est utilisé, le chiffrement sera de qualité sauf si le serveur ET le client ont un chiffrement faible. Firefox avec un apache va utiliser du DH/AES256 par défaut, pas IE)
le gros risque c'est que la clé de session soit faible.
je ne sais pas si le générateur aléatoire en cause est utilisé pour la clé de session
SSL, comme les autres protocoles hybrides, est dépendant de la faiblesse de la crypto publique, et de la crypto privée... si l'un des 2 est faible, tout saute.
ainsi si la clé de session est faible, pas besoin de déchiffrer le RSA ou le DH, il suffit de déchiffrer le DES ou l'AES avec quelques milliers de clés non aléatoires.
donc, si quelqu'un a mémorisé des flux SSL, il pourra les déchiffrer
