Posted: Thu May 15, 2008 4:10 am Post subject: faille openssl debian
Bonjour,
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 ?
Posted: Thu May 15, 2008 1:03 pm Post subject: Re: faille openssl debian
mpg wrote:
Quote:
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:
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.
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)...
Quote:
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.
Quote:
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 ?
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 :-(
Posted: Thu May 15, 2008 1:10 pm Post subject: Re: faille openssl debian
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.
Posted: Thu May 15, 2008 6:10 pm Post subject: Re: faille openssl debian
mpg wrote:
Quote:
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).
Posted: Thu May 15, 2008 6:10 pm Post subject: Re: faille openssl debian
"A. Caspis" <a_caspis@yahoo.com> écrivait :
Quote:
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é
Posted: Thu May 15, 2008 6:10 pm Post subject: Re: faille openssl debian
Erwan David wrote:
Quote:
Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils
openssl ?
Les vieux outils à base de passphrase + hash + algo symétrique
ne doivent pas être concernés puisqu'ils n'utilisent pas d'aléa.
Les nouveaux qui génèrent une clé aléatoire et la stockent sur
disque, protégée par un mot de passe, pourraient être affectés.
Concernant dm-crypt, il semble qu'on ait de la chance parce que
les utilitaires sont conçus pour lire la clé depuis /dev/random
plutôt que pour la générer eux-mêmes.
The following cryptographic tools are unaffected:
* cryptsetup (neither LUKS nor the regular dm-crypt use openssl,
the openssl keyscript - which is not used in any default
installations - does use openssl, but only to encrypt the key,
not to actually generate the key that is used to encrypt the
partition, the encryption of the key may therefore be less strong
than expected but the key itself is not)
Et encore la dernière phrase ci-dessus me semble superflue:
soit la clé est mal protégée, et on peut la récupérer même si elle
n'est pas affaiblie; soit elle est chiffrée normalement (et il n'y
a pas de raison que ça fasse appel à un RNG) et tout va bien.
Posted: Thu May 15, 2008 6:10 pm Post subject: Re: faille openssl debian
A. Caspis a écrit :
Quote:
Erwan David wrote:
Il y a aussi les partitions chiffrées : dm-crypt ou encfs utilisent-ils
openssl ?
Les vieux outils à base de passphrase + hash + algo symétrique
ne doivent pas être concernés puisqu'ils n'utilisent pas d'aléa.
Les nouveaux qui génèrent une clé aléatoire et la stockent sur
disque, protégée par un mot de passe, pourraient être affectés.
Concernant dm-crypt, il semble qu'on ait de la chance parce que
les utilitaires sont conçus pour lire la clé depuis /dev/random
plutôt que pour la générer eux-mêmes.
je n'ai pas tout suivi mais j'espère qu'ils n'utiliseront pas
/dev/random pour colmater parce que un serveur ssh et /dev/random
ne peuvent pas faire bon ménage l' entropie de /dev/random est liée
à son utilisation
en gros plus on l'utilise et plus la "qualité est mauvaise"
par contre
/dev/random +http://fr.wikipedia.org/wiki/Blum_Blum_Shub
ou
/dev/random +http://remyaumeunier.chez-alice.fr/alea.html
mais le deuxième est à vos risques et périls et le premier
a un petit problème lié à son cycle donc on le réinitialise après
M tirage
Posted: Thu May 15, 2008 6:10 pm Post subject: Re: faille openssl debian
A. Caspis wrote:
Quote:
[...]
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 ?)
Posted: Thu May 15, 2008 11:10 pm Post subject: Re: faille openssl debian
Jean-Marc Desperrier wrote:
Quote:
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)
Quote:
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 :)
Posted: Thu May 15, 2008 11:10 pm Post subject: Re: faille openssl debian
A. Caspis wrote:
Quote:
[...]
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.
Posted: Fri May 16, 2008 8:10 am Post subject: Re: faille openssl debian
Jean-Marc Desperrier a écrit :
Quote:
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
Il semble le plus probable que cela ne fasse