Je suis tombé là dessus sur la ML de Debian Security : http://www.win.tue.nl/hashclash/rogue-ca/
Ca fait peur que des autorités de certification comme Verisign utilisent encore MD5 pour signer leur certificats. Pour ceux qui ne veulent pas lire, vérifiez que les certificats des sites que vous visitez ne sont pas signés avec MD5.
PS : sésolé du petit journal (je n'ai pas eu le temps de tout lire travail oblige !), mais devant l'importance de la chose et le fait que personne encore n'en a parlé ici j'ai décidé de poster le lien sans détailler.
# La réponse de verisign
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[1] https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabi(...)
[^] # Re: La réponse de verisign
Posté par Victor STINNER (site web personnel) . Évalué à 6.
http://www.heise-online.co.uk/security/Verisign-RapidSSL-clo(...)
Verisign are in the process of discontinuing the use of MD5 hashes for signing, saying it had been planning to stop use of MD5 in customer certificates by the end of January 2009
Il est certain que la conférence du CCC soit liée à ce changement !
# Mouais
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Une autoritée acceptée par les navigateurs qui donne des certificats sans vérifier qu'on est propriétaire du domaine en question, et une semaine après que cela ait été signalé aucune mesure n'a encore été prise contre ce CA.
Un autre problème. Le certificat en question a été révoqué par le CA après le bruit que ca a fait, mais comme je le dis en commentaire de http://taosecurity.blogspot.com/2008/12/traffic-for-revoked-(...) ça n'empeche pas de l'utiliser pour une attaque...
# "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par Sarcastic . Évalué à 5.
Cependant Satirov se veut plutôt rassurant : Selon lui l'attaque est difficile à répéter : il faudrait plus de 6 mois pour arriver à contrefaire un certificat avec une implémentation naïve.
Enfin, ça va (peut-être ?) être le branle-bas de combat : révoquer les certificats utilisant MD5, mettre à jour les navigateurs pour générer une alerte de sécurité quand MD5 est utilisé.
http://blogs.zdnet.com/security/?p=2339
Le Web aura eu la vie dure cette année : les certificats SSL de Debian frelatés, la faille du protocole DNS…
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par claudex . Évalué à 2.
Ça montre peut-être que, grâce à son expension, le web devient plus sérieux.
Le problème, à mon avis, c'est que les gens qui utilisent le web avec des applications critiques mais dont le web n'est pas le métier (genre les banques) ne se posent pas la question de savoir si leur site sécurisé est vraiment sécurisé (enfin les banques ont autre chose à faire pour le moment).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par Aefron . Évalué à 4.
Pour Debian, ça a été pire : ce ne sont pas que les certificats, mais toutes les clés générées par OpenSSL, qui ont été touchées - et comme on peut le voir, la liste de ce qui est potentiellement impacté est longue [1]. Dailleurs, depuis, je me suis acheté des smartcards : je ne les utilise pas pour tout (il m'en faudrait trop, et sur les serveurs, en cas de redémarrage, ce serait très chiant), mais c'est déjà ça.
Par contre, pour le protocole DNS, ce n'est pas tant une faille qu'une vulnérabilité intrinsèque... autant DNS est quelque chose de crucial, autant ça se trimballe une sécurité de loutre bourrée : stateless avec UDP, en pratique : pas de chiffrement/authentification des DNS récursifs des FAI et cie, entropie artisanale comme garde-fou le plus courant contre la forge de réponse erronées...
Sans compter le côté "si-si, je fais tout - je suis un enfer à configurer, et j'ai tendance à avoir une conf anti-sekioure par défaut, mais je fais tout" de Bind, probablement le serveur le plus utilisé dans le monde libre (chez moi, c'est pdns-recursor pour la récursion interne, unbound pour le cache commun à tout le monde, et nsd pour l'autoritaire - et l'expérience m'a montré qu'avec cette ségrégation, d'autant que j'utilise plusieurs pdns-recursor et nsd, pour reproduire le comportement des "views" de bind, il y a moins de danger de se tirer une balle dans le pied).
Bah, forcément : avec, par exemple, l'augmentation des vitesses des connexions et l'augmentation du nombre de machines sur le net, ça _devait_ arriver... ça doit faire dans les 15 ans qu'on _sait_ que DNS est fragile comme de la porcelaine, et que si on peut gagner de l'entropie pour rendre plus ardu la forge de réponse malintentionnées, il _faut_ le faire... youpi : les ténors gras comme des loukoums se sont bougés en même temps pour tous mettre une rustine à un problème maintenant antique - m'enfin, à terme, ce n'est toujours pas ça qui va empêcher que ça va trancher...
[1] http://wiki.debian.org/SSLkeys
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par Kerro . Évalué à 3.
Bind, probablement le serveur le plus utilisé dans le monde libre
Le fait qu'un logiciel soit très utilisé ne reflète pas sa qualité. Clairement, bind est un exemple :-) Pourquoi les unixiens seraient plus malins que les autres ? On leur a appris bind à l'école, alors ils utilisent bind.
En entretien d'embauche j'ai eu un questionnaire dont la partie dns était uniquement composée de question genre "quel est le nom du fichier de configuration d'un serveur dns ?" "quelle est la syntaxe pour déclarer un CNAME ?" etc. Ca n'est pas passé lorsque j'ai répondu genre "avec pdns c'est xxx" "avec djbdns c'est yyy". Le super informaticien qui avait pondu ce truc ne savait même pas qu'il existait autre chose que bind.
pdns-recursor [...] unbound [...] nsd
Même chose ici. Simple. Robuste. Fiable.
Un reproche à pdns: dès qu'on veut des informations précises, la seule documentation valable est le code source. C'est moyen :-)
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par NickNolte . Évalué à 2.
DNS-recursor
DNS-common-cache (ok, unbound fait plus que ça)
DNS-auth
ça serait fichtrement plus simple, non?
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par Kerro . Évalué à 9.
apache --> famous-web-server
Boa --> another-web-server
Caudium --> another-again-web-server
lighttpd --> light-web-server
TUX web server --> stupidly-named-web-server
linux --> os-kernel
lynx --> web-broswer-for-real-men
Mozilla Firefox --> challenger-web-broswer
Opera --> less-known-challenger-web-broswer
etc etc
[^] # Re: "We basically broke SSL" annonce Alex Sotirov au CCC
Posté par NickNolte . Évalué à 1.
Tu sais, il n'y a pas que l'anglais pour créer des noms de projet... un même nom commun balancé dans une autre langue (russe, turc, italien...) et hop, une particularité, une!.
Biensûr on pourrait également jouer sur la graphie de certains mots, histoire d'ajouté une ptite note stylistique.
Enfin...
# MD5 considered harmful today
Posté par IsNotGood . Évalué à 3.
C'est un vieux problème il me semble. Au moins 1 ans. Probablement 2.
[^] # Re: MD5 considered harmful today
Posté par Ellendhel (site web personnel) . Évalué à 2.
http://fr.wikipedia.org/wiki/MD5
De mémoire, les quatre chercheurs avaient réussi à obtenir deux MD5 identiques pour des fichiers PDF différents (il me semble que la collision avait été générée spécifiquement).
Même Microsoft le signale aujourd'hui, tout le monde s'en inquiète :
http://www.microsoft.com/france/technet/security/advisory/96(...)
[^] # Re: MD5 considered harmful today
Posté par Bernez . Évalué à 3.
Question. Where does the title "MD5 considered harmful today" of this website come from?
Answer. In December 2004, shortly after MD5 collisions were found, Dan Kaminsky came with an exploit for them. His paper is entitled "MD5 to be considered harmful someday", see [K1]. We think this day has come.
[^] # Re: MD5 considered harmful today
Posté par IsNotGood . Évalué à 2.
# et OpenVPN?
Posté par kboo80 . Évalué à 1.
[^] # Re: et OpenVPN?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
De quoi tu parles ? Si tu fais référence à la précédente faille OpenSSL Debian, elle est corrigé depuis plusieurs mois.
[^] # Re: et OpenVPN?
Posté par Sarcastic . Évalué à 2.
Après, la partie chiffrement est intacte, et je pense que pour le VPN ça n'aura pas d'impact (je peux me tromper, cependant).
[^] # Re: et OpenVPN?
Posté par kboo80 . Évalué à 1.
<< "We basically broke SSL" annonce Alex Sotirov au CCC>>
[^] # Re: et OpenVPN?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: et OpenVPN?
Posté par Sarcastic . Évalué à 2.
1. Ça demande une attaque Man-in-the-Middle, ce qui a au final assez peu de chance d'arriver au niveau du particulier utilisant un VPN (pas vraiment utile de passer plusieurs jours de temps machine pour un gain aussi faible, d'aller arnaquer les DNS ou des caches ARP si tu utilises directement ton IP).
2. L'attaque est encore une fois assez complexe, et il est dit qu'avec une implémentation naïve elle prendrait au moins 6 mois avant d'aboutir.
3. Je me demande si l'attaque marcherait dans ce cas : le certificat étant a priori auto-signé et c'est tout, pas de dispersions de certificats fils. Faudrait lire l'attaque avec soin, ce que j'avoue avoir la flemme de faire là maintenant.
[^] # Re: et OpenVPN?
Posté par kboo80 . Évalué à -1.
Une source :
http://www.clubic.com/actualite-248742-securite-200-ps3-gene(...)
# L'avis de Bruce
Posté par pix (site web personnel) . Évalué à 2.
Dixit Bruce Schneier:
But SSL doesn't provide much in the way of security, so breaking it doesn't harm security very much. Pretty much no one ever verifies SSL certificates, so there's not much attack value in being able to forge them. And even more generally, the major risks to data on the Internet are at the endpoints -- Trojans and rootkits on users' computers, attacks against databases and servers, etc -- and not in the network.
http://www.schneier.com/blog/archives/2008/12/forging_ssl_ce(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.