Des chercheurs suisses de l’école polytechnique fédérale de Lausanne ont réussi à “casser” le principal système de cryptage de données sur Internet : le SSL (Secure Socket Layer). Ce système est utilisé par la quasi-totalité des sites marchands sur la toile, mais apparemment le défaut utilisé touche surtout le webmail, pas la partie bancaire du protocole.
Plus de détails sur slashdot.org, plus particulièrement dans cet article.
Effectivement, mais ce n’est pas très alarmant. C’est très classique comme faille. D’ailleurs c’est étonnant qu’ils n’y aient pas pensé plus tôt. Je vous traduis (putain c’est ça que j’aurais dû faire comme métier ;)) la news :
« Le défaut réside dans l’implémentation, pas dans le protocole. Vu la façon dont les contrôles d’erreur étaient implantés, un pirate pouvait découvrir quelle condition d’erreur avait foirée en mesurant la réponse. La solution est triviale : il suffit de forcer OpenSSL à effectuer le second contrôle même quand le premier échouait, empêchant ainsi le pirate de récupérer une quelconque info telle que la condition d’erreur qui a fait planter son attaque. »
Bref le patch ne devrait pas tarder à arriver. 
foirée => foiré hum
Pour que ce commentaire soit un peu plus instructif, disons que la solution envisagée est facile à mettre en place mais que théoriquement, il restera une faille. En effet, avec cette technique de patch, on ne pourra plus savoir quel test a foiré, MAIS on aura toujours la possibilité de savoir à combien de tests a échoué l’attaque du pirate. Bon cette info est mince, mais ça n’en reste pas moins une info pertinente et à risque. Cette news en est la preuve : Et oui, on pensait à l’époque que ne pas savoir l’erreur était un niveau suffisant de sécurité, ce qui vient d’être infirmé ici car la durée de renvoi de réponse permet d’être fixé Il suffirait donc de faire des combi de tests en attaquant la machine… Bref, ça restera possible tant qu’ils ne mettent pas en place un truc du genre « si erreur(s), retourne réponse au bout de k ms. » avec k constant bien sûr…
Putain, même pendant les vacances, ils bossent ceux-là? (oui, à l’EPFL on est en vacances pour 4 semaines…)
C’est exactement ca que le patch de OpenSSL règle… Il retournait déjà avant le même message d’erreur. Le patch modifie simplement le moment ou le message est renvoyé (toujours après le test MAC) pour éviter la timing attack…
Merci du renseignement alors, car la solution donnée en premier n’évitait pas une timing attack indirecte
Comment ça en vacances ?!? Il n’y a que les étudiants qui sont en vacances… et encore, seulement les 1ère ou 2ème année 
ils sont quand même trop fort à l’EPFL