Commentaires
Contre heartbleed, pour une hygiène des mots de passe !
La sécurité des achats sur internet, la confidentialité de nos mots de passe et de toutes nos données, sont-elles menacées par la faille Heartbleed, ou bien s'alarme-t-on trop vite ? Notre émission tente de décrypter de façon pédagogique les causes et les implications de cette faille, qui fait frémir le Web. Accessoirement, vous découvrirez que l'heure n'est plus aux mots de passe, mais aux "phrases de passe". Et que l'incident nous amène à réfléchir sur une exploitation "responsable" des logiciels libres.
Abonnez-vous pour pouvoir commenter !
si vous êtes déjà abonné Connectez-vous Connectez-vous
Derniers commentaires
[quote=MasterTigrou]
c'est vrai, je reconnais mon erreur d'appréciation de la gravité --potentielle -- la communauté logicielle n'a pas si mal réagi et les "rustines" sont bien appliquées. Benjamin par son message de 14 H 44 min le 18 avril, nous rassure : [opensslrampage.org] .
Please consider donating to support our efforts.
LibreSSL is a FREE version of the SSL/TLS protocol forked from OpenSSL
At the moment we are too busy deleting and rewriting code to make a decent web page.
Please consider donating to support our efforts.
No we don't want help making web pages, thank you. <--- humour de développeur de très haut niveau.
Multi OS support will happen once we have
Flensed, refactored, rewritten, and fixed enough of the code so we have stable baseline that we trust and can be maintained/improved.
The right Portability team in place.
A Stable Commitment of Funding to support an increased development and porting effort.
LibreSSL is primarily developed by the OpenBSD Project, and its first inclusion into an operating system will be in OpenBSD 5.6.
LibreSSL is supported financially by The OpenBSD Foundation as well as by the The OpenBSD Project. Please consider donating to support our efforts.
c'est vrai, je reconnais mon erreur d'appréciation de la gravité --potentielle -- la communauté logicielle n'a pas si mal réagi et les "rustines" sont bien appliquées. Benjamin par son message de 14 H 44 min le 18 avril, nous rassure : [opensslrampage.org] .
Please consider donating to support our efforts.
LibreSSL is a FREE version of the SSL/TLS protocol forked from OpenSSL
At the moment we are too busy deleting and rewriting code to make a decent web page.
Please consider donating to support our efforts.
No we don't want help making web pages, thank you. <--- humour de développeur de très haut niveau.
Multi OS support will happen once we have
Flensed, refactored, rewritten, and fixed enough of the code so we have stable baseline that we trust and can be maintained/improved.
The right Portability team in place.
A Stable Commitment of Funding to support an increased development and porting effort.
LibreSSL is primarily developed by the OpenBSD Project, and its first inclusion into an operating system will be in OpenBSD 5.6.
LibreSSL is supported financially by The OpenBSD Foundation as well as by the The OpenBSD Project. Please consider donating to support our efforts.
Excellente émission. Je suis étonné de ne pas avoir été pris de vitesse par les clavioteurs les plus rapides au moment d'intervenir sur ce forum. Plusieurs très bonnes informations ont été données pendant l'émission :
a) ma compréhension de la "gravité " de la faille de sécurité est qu'elle n'est peut-être pas si gravissime que ça. Un ordinateur 'client' adresse une *requête* <-- ;^)) pour D.S. bon Candide voltairien «requête» est une "implémentation" de «demande» ;? ) à un serveur et qu'en réponse ce dernier envoie beaucoup plus de koctets -- ou mégaoctets-- que ce qu'il eut été sain d'envoyer, hé bien n'oublions pas que ce qui vient en plus, le rabiot ( 'supplément, rab' ) sera certainement du «dump» de mémoire ! dump en informatique=> vidage tel quel des octets de la mémoire = du code machine. [dump dans vie courante--> tas de détritus, déchets -- ou dépôt de munitions! ] Et là il faut des vicelards super organisés et hyper bien équipés pour aller fouiller dans ce tout-venant, codé si les responsables de serveurs sont sérieux, vicelards comme la NSA et ses officines, pour *éventuellement * trouver quelque-chose d'exploitable.
Bon, maintenant il est mieux que comme cela a été fait rapidement la faille soit "patchée" (rapiécée ) un patch est soit un pansement ou même une "pièce" vulcanisée sur une chambre à air.....[Rustine, comme Frigidaire sont des marques déposées " copyrightées, cré Bon Dieu... ]
b) émission tellement riche en renseignements de valeur, je termine en vous faisant part du profit que j'ai tiré d'une de ces infos, et pourtant pas une du plus haut rang, mais "intéressante" voyez ;^)))
SSL Report: arretsurimages.net (91.121.42.18)
Assessed on: Tue Apr 22 08:18:51 UTC 2014 | 12 H 18 min 51 s RET (Réunion Time- Indian Ocean)
Assessment failed: No secure protocols supported
Known Problems
There are some errors that we cannot fix properly in the current version. They will be addressed in the next generation version, which is currently being developed.
No secure protocols supported - if you get this message, but you know that the site supports SSL, wait until the cache expires on its own, then try again, making sure the hostname you enter uses the "www" prefix (e.g., "www.ssllabs.com", not just "ssllabs.com").
no more data allowed for version 1 certificate - the certificate is invalid; it is declared as version 1, but uses extensions, which were introduced in version 3. Browsers might ignore this problem, but our parser is strict and refuses to proceed. We'll try to find a different parser to avoid this problem.
Failed to obtain certificate and Internal Error - errors of this type will often be reported for servers that use connection rate limits or block connections in response to unusual traffic. Problems of this type are very difficult to diagnose. If you have access to the server being tested, before reporting a problem to us, please check that there is no rate limiting or IDS in place.
NetScaler issues - some NetScaler versions appear to reject SSL handshakes that do not include certain suites or handshakes that use a few suites. If the test is failing and there is a NetScaler load balancer in place, that's most likely the reason.
Common Error Messages
Connect timed out - server did not respond to our connection request, sometimes before we are dynamically blocked when our tests are detected
No route to host - unable to reach the server
Unable to connect to server - failed to connect to the server
Connection reset - we got disconnected from the server
Unrecognized SSL message, plaintext connection? - the server responded with plain-text HTTP on HTTPS port
Received fatal alert: handshake_failure - this is either a faulty SSL server or some other server listening on port 443; if the SSL version of the web site works in your browser, please report this issue to us
SSL Report v1.9.22
Ce résultat à la «nous sommes rassurés par notre inimitable ligne Maginot !!....» vient de
https://www.ssllabs.com/ssltest/analyze.html?d=arretsurimages.net
Assessment failed: No secure protocols supported Echec à l'évaluation (contrôle continu, examen ) candidat arretsurimages.net *RECALé* !
a) ma compréhension de la "gravité " de la faille de sécurité est qu'elle n'est peut-être pas si gravissime que ça. Un ordinateur 'client' adresse une *requête* <-- ;^)) pour D.S. bon Candide voltairien «requête» est une "implémentation" de «demande» ;? ) à un serveur et qu'en réponse ce dernier envoie beaucoup plus de koctets -- ou mégaoctets-- que ce qu'il eut été sain d'envoyer, hé bien n'oublions pas que ce qui vient en plus, le rabiot ( 'supplément, rab' ) sera certainement du «dump» de mémoire ! dump en informatique=> vidage tel quel des octets de la mémoire = du code machine. [dump dans vie courante--> tas de détritus, déchets -- ou dépôt de munitions! ] Et là il faut des vicelards super organisés et hyper bien équipés pour aller fouiller dans ce tout-venant, codé si les responsables de serveurs sont sérieux, vicelards comme la NSA et ses officines, pour *éventuellement * trouver quelque-chose d'exploitable.
Bon, maintenant il est mieux que comme cela a été fait rapidement la faille soit "patchée" (rapiécée ) un patch est soit un pansement ou même une "pièce" vulcanisée sur une chambre à air.....[Rustine, comme Frigidaire sont des marques déposées " copyrightées, cré Bon Dieu... ]
b) émission tellement riche en renseignements de valeur, je termine en vous faisant part du profit que j'ai tiré d'une de ces infos, et pourtant pas une du plus haut rang, mais "intéressante" voyez ;^)))
SSL Report: arretsurimages.net (91.121.42.18)
Assessed on: Tue Apr 22 08:18:51 UTC 2014 | 12 H 18 min 51 s RET (Réunion Time- Indian Ocean)
Assessment failed: No secure protocols supported
Known Problems
There are some errors that we cannot fix properly in the current version. They will be addressed in the next generation version, which is currently being developed.
No secure protocols supported - if you get this message, but you know that the site supports SSL, wait until the cache expires on its own, then try again, making sure the hostname you enter uses the "www" prefix (e.g., "www.ssllabs.com", not just "ssllabs.com").
no more data allowed for version 1 certificate - the certificate is invalid; it is declared as version 1, but uses extensions, which were introduced in version 3. Browsers might ignore this problem, but our parser is strict and refuses to proceed. We'll try to find a different parser to avoid this problem.
Failed to obtain certificate and Internal Error - errors of this type will often be reported for servers that use connection rate limits or block connections in response to unusual traffic. Problems of this type are very difficult to diagnose. If you have access to the server being tested, before reporting a problem to us, please check that there is no rate limiting or IDS in place.
NetScaler issues - some NetScaler versions appear to reject SSL handshakes that do not include certain suites or handshakes that use a few suites. If the test is failing and there is a NetScaler load balancer in place, that's most likely the reason.
Common Error Messages
Connect timed out - server did not respond to our connection request, sometimes before we are dynamically blocked when our tests are detected
No route to host - unable to reach the server
Unable to connect to server - failed to connect to the server
Connection reset - we got disconnected from the server
Unrecognized SSL message, plaintext connection? - the server responded with plain-text HTTP on HTTPS port
Received fatal alert: handshake_failure - this is either a faulty SSL server or some other server listening on port 443; if the SSL version of the web site works in your browser, please report this issue to us
SSL Report v1.9.22
Ce résultat à la «nous sommes rassurés par notre inimitable ligne Maginot !!....» vient de
https://www.ssllabs.com/ssltest/analyze.html?d=arretsurimages.net
Assessment failed: No secure protocols supported Echec à l'évaluation (contrôle continu, examen ) candidat arretsurimages.net *RECALé* !
Merci pour toutes ces infos :)
Par contre, je trouve que le temps de parole n'était pas assez réparti entre les deux "invités".
Par contre, je trouve que le temps de parole n'était pas assez réparti entre les deux "invités".
Ce message a été supprimé suite à la suppression du compte de son auteur
... Roohhh ! On ne dit pas "Eurtblid" mais "Heartbleed" > Heart = coeur = [hart]
http://commons.wikimedia.org/w/index.php?title=File%3AEn-uk-heart.ogg
http://commons.wikimedia.org/w/index.php?title=File%3AEn-uk-heart.ogg
Une vrai question levée par cet enorme bug est la confiance que met la communauté des professionnels de l'informatique (dont je suis) dans un logiciel ultra critique dont ont ne sait ... a peu pres rien. Il faut constater que cette confiance est aveugle, et c'est flippant.
Nous avons les moyens techniques de savoir simplement qui sont les développeurs de OpenSSL, combien ils sont, comment ils codent, avec quels outils, quelles règles et quelle méthodologie. On peut savoir qui a écrit telle ligne de code, a quelle heure, et dans quel but.C'est cela l'open source. C'est bien, mais manifestement très insufisant. Aucun d'entre nous (informaticiens), ou si peu, ne prends la peine de s'en soucier. On se dit à tort qu'un logiciel de cette importance est forcément l'objet d'une attention massive et minutieuse, par une cohorte de contributeurs zêlés et financés par l'industrie toute entière. Eh bien non, il s'agit d'une poignée de volontaires, qui malgré un dévouement sans doute important, commet des erreurs triviales et utilise peu de méthodologie à même de réduire certains risques pourtant bien connus (voir utilisent des méthodologies qui accroissent le risque!).
Pour moi, c'est la leçon essentielle. A qui accordons nous notre confiance et sur quelles bases ? Dans le monde informatique, la confiance est une denrée qui ne vaut pas cher... on la distribue sans réfléchir, parce qu'il faut avouer que personne y comprends grand chose.
Nous avons les moyens techniques de savoir simplement qui sont les développeurs de OpenSSL, combien ils sont, comment ils codent, avec quels outils, quelles règles et quelle méthodologie. On peut savoir qui a écrit telle ligne de code, a quelle heure, et dans quel but.C'est cela l'open source. C'est bien, mais manifestement très insufisant. Aucun d'entre nous (informaticiens), ou si peu, ne prends la peine de s'en soucier. On se dit à tort qu'un logiciel de cette importance est forcément l'objet d'une attention massive et minutieuse, par une cohorte de contributeurs zêlés et financés par l'industrie toute entière. Eh bien non, il s'agit d'une poignée de volontaires, qui malgré un dévouement sans doute important, commet des erreurs triviales et utilise peu de méthodologie à même de réduire certains risques pourtant bien connus (voir utilisent des méthodologies qui accroissent le risque!).
Pour moi, c'est la leçon essentielle. A qui accordons nous notre confiance et sur quelles bases ? Dans le monde informatique, la confiance est une denrée qui ne vaut pas cher... on la distribue sans réfléchir, parce qu'il faut avouer que personne y comprends grand chose.
Bon c'était pas passionnant, mais j'ai quand même été au bout pour savoir quand l'accès à arretsurimages.net serait (enfin) disponible en SSL/TLS. Malheureusement DS, tout à ses efforts de pédagogie a oublié de nous donner la date.
Maintenant que tout le monde est sensibilisé aux moyen de garantir la confidentialité de ses échanges, la foule piaffe d'impatience de pouvoir troller sur le forum sans être à la merci de potentielles indiscrétions d'éventuels administrateurs réseaux indélicats chez son FAI.
Maintenant que tout le monde est sensibilisé aux moyen de garantir la confidentialité de ses échanges, la foule piaffe d'impatience de pouvoir troller sur le forum sans être à la merci de potentielles indiscrétions d'éventuels administrateurs réseaux indélicats chez son FAI.
Bonjour,
Emission très intéressante, juste une question : est-ce qu'on pourrait avoir le lien de la vidéo de la CNIL citée par JM Manach à la fin à propos du coffre-fort numérique ?
Merci !
Emission très intéressante, juste une question : est-ce qu'on pourrait avoir le lien de la vidéo de la CNIL citée par JM Manach à la fin à propos du coffre-fort numérique ?
Merci !
J'oublie juste un détail qui balaye ma précédente intervention :
OpenSSL est juste la base du protocole SSL, qui est un protocole de communication sécurisé entre un client et un serveur. Si tout cela est vrai, la faille est énorme et concerne tous les serveurs utilisant ce protocole pour la connexion au serveur et la transition d'informations cryptées.
Cependant il est à noter que les données circulant sur le serveur restent cryptées : même si le hacker télécharge les données, les mots de passe ne sont JAMAIS en circulation sans cryptage dans la mémoire du serveur. Autrement dit, il y a de fortes chances que le hacker ne puisse rien faire des mots de passe extraits, à moins que le serveur ai vraiment été tres mal codé. Par contre, il pourrait accéder aux données non cryptées. Autrement dit, vous avez un truc à mettre dans votre serveur qui est confidentiel et critique ? Cryptez le ... Et je pense que la majorité des serveurs le font. Je n'ai jamais vu un projet de serveur avec une base de donnée ou le mot de passe n'est pas crypté. Ce serait d'un manque de sérieux total. Les serveurs sont normalement codés pour résister un tant soit peu à une intrusion via différents niveaux de sécurité.
Peut être qu'après on peut envisager le fait que le cryptage du mot de passe soit cassable, mais a priori, le cryptage SSL reste ce qu'il y a de plus sur non ? Y a t'il peut être un moyen de récuperer les clés de cryptage via le heartbleed ? Ca me parait complètement improbable.
Encore une fois, je ne suis pas expert sur cette question et je serais vraiment très interessé par la réponse de quelqu'un de plus compétent que moi sur le domaine.
Merci beaucoup pour cette émission (et bravo pour la selection des sujets du 14h42 qui sont [selon moi] toujours tres pertinents).
OpenSSL est juste la base du protocole SSL, qui est un protocole de communication sécurisé entre un client et un serveur. Si tout cela est vrai, la faille est énorme et concerne tous les serveurs utilisant ce protocole pour la connexion au serveur et la transition d'informations cryptées.
Cependant il est à noter que les données circulant sur le serveur restent cryptées : même si le hacker télécharge les données, les mots de passe ne sont JAMAIS en circulation sans cryptage dans la mémoire du serveur. Autrement dit, il y a de fortes chances que le hacker ne puisse rien faire des mots de passe extraits, à moins que le serveur ai vraiment été tres mal codé. Par contre, il pourrait accéder aux données non cryptées. Autrement dit, vous avez un truc à mettre dans votre serveur qui est confidentiel et critique ? Cryptez le ... Et je pense que la majorité des serveurs le font. Je n'ai jamais vu un projet de serveur avec une base de donnée ou le mot de passe n'est pas crypté. Ce serait d'un manque de sérieux total. Les serveurs sont normalement codés pour résister un tant soit peu à une intrusion via différents niveaux de sécurité.
Peut être qu'après on peut envisager le fait que le cryptage du mot de passe soit cassable, mais a priori, le cryptage SSL reste ce qu'il y a de plus sur non ? Y a t'il peut être un moyen de récuperer les clés de cryptage via le heartbleed ? Ca me parait complètement improbable.
Encore une fois, je ne suis pas expert sur cette question et je serais vraiment très interessé par la réponse de quelqu'un de plus compétent que moi sur le domaine.
Merci beaucoup pour cette émission (et bravo pour la selection des sujets du 14h42 qui sont [selon moi] toujours tres pertinents).
J'oublie juste un détail qui balaye ma précédente intervention :
OpenSSL est juste la base du protocole SSL, qui est un protocole de communication sécurisé entre un client et un serveur. Si tout cela est vrai, la faille est énorme et concerne tous les serveurs utilisant ce protocole pour la connexion au serveur et la transition d'informations cryptées.
Soyons clair : OpenSSL = une implémentation de TSL/SSL. Le mot que J.M.S ne voulait pas utiliser (c'est certes un anglicisme mais il exprime vraiment bien les choses).
SSL et TLS sont décrits dans leur principe (qui est lui clairement sécurisé) par un organisme de normalisation.
Par contre tout le monde peut proposer un code qui traduit en terme de programme cette spécification.
Or, dans l'extension Heartbit de OpenSSL, un chercheur Allemand a utilisé une fonction qui lit jusqu'à 64ko (taille donnée sur 15 bits) de données dans la mémoire alors que seul 3 ou 4 octets sont demandés au départ. C'est ce qu'on appelle un buffer overflow, c'est pour ça que dans la vidéo, il est dit que c'est une faille "simple".
Cependant il est à noter que les données circulant sur le serveur restent cryptées : même si le hacker télécharge les données, les mots de passe ne sont JAMAIS en circulation sans cryptage dans la mémoire du serveur.
Si, ils sont un jour décryptés ! et mis en RAM pour être ensuite hashé et comparé à ce qu'il y a en bdd.
OK on est d'accord. Les mots de passe dans la DB sont hashés (cryptage irréversible), et quand il reçoit le mot de passe d'un client, il le décrypte pour le hasher et le faire correspondre à celui de la DB.
Donc le hacker utilisant heartbleed peut extraire les mots de passe en cours de traitement par le serveur juste apres leur décryptage le temps de la comparaison, mais pas ceux dans la Database, vu qu'ils sont deja hashés et donc irreversibles.
Il suffit donc qu'il utilise cette faille sur une longue durée pour récolter un grand nombre de mots de passe. Mais si par exemple j'utilise une connexion SSL avec une clé publique, il ne peut rien faire le gars non ?
Merci.
Donc le hacker utilisant heartbleed peut extraire les mots de passe en cours de traitement par le serveur juste apres leur décryptage le temps de la comparaison, mais pas ceux dans la Database, vu qu'ils sont deja hashés et donc irreversibles.
Il suffit donc qu'il utilise cette faille sur une longue durée pour récolter un grand nombre de mots de passe. Mais si par exemple j'utilise une connexion SSL avec une clé publique, il ne peut rien faire le gars non ?
Merci.
Il suffit donc qu'il utilise cette faille sur une longue durée pour récolter un grand nombre de mots de passe. Mais si par exemple j'utilise une connexion SSL avec une clé publique, il ne peut rien faire le gars non ?
On est sur un buffer overflow : ça signifie qu'il dépasse la mémoire qui lui est alloué. Une fois qu'un espace mémoir est désaloué, les valeurs qu'il avait dans cette mémoire ne sont pas forcément effacées et si par chance il y avait plusieurs mots de passe alloués dans les 64ko, bah on les a.
De plus n'oublie pas que pour obtenir une simple clef privée (2048 bits), il a fallu plus de 60 000 essais. Quand les gens ont pris les id de sécu, ils ont dû en faire encore plus (et je pense que c'est pour ça que l'organisme a détecté la faille : au début ils ont dû croire que c'était une attaque de flooding, puis ils se sont rendu compte du problème.
La clé privée n'est accessible que juste après le redémarrage du serveur. Ensuite il y a des allocations entre elle et les 64 ko lisibles qui la rendent inaccessible.
Dans le concours où une clé a été extraite en 6h, elle l'a en fait été juste après un redémarrage.
Dans le concours où une clé a été extraite en 6h, elle l'a en fait été juste après un redémarrage.
ça ne change rien au problème de départ, sans compter que les fameuses allocations sont imprévisibles puisqu'aléatoires (on est sur le tas).
On est ici sur de l'aléatoire. Ca signifie juste qu'on est capable de donner une loi de probabilité, certainement pas d'être certain que ça arrivera.
Donc oui, il est hautement improbable qu'on en tire les mots de passe, mais comme dans toute étude probabiliste, improbable ne signifie pas impossible !
On est ici sur de l'aléatoire. Ca signifie juste qu'on est capable de donner une loi de probabilité, certainement pas d'être certain que ça arrivera.
Donc oui, il est hautement improbable qu'on en tire les mots de passe, mais comme dans toute étude probabiliste, improbable ne signifie pas impossible !
On extrait les mots de passes et les cookies de sessions que le serveur vient de manipuler.
Sur l'aspect aléatoire, c'est vrai que l'ASLR devrait protéger, sauf que OpenSSL a implémenté son propre allocateur par dessus celui de la libc, ce qui fait qu'ils ne bénéféciaient pas de l'ASLR, autant que je comprenne.
Sur l'aspect aléatoire, c'est vrai que l'ASLR devrait protéger, sauf que OpenSSL a implémenté son propre allocateur par dessus celui de la libc, ce qui fait qu'ils ne bénéféciaient pas de l'ASLR, autant que je comprenne.
SSL et TLS sont décrits dans leur principe (qui est lui clairement sécurisé)
... aux bugs de conception près ;-)
Attacks against TLS/SSL (Wikipédia)
... aux bugs de conception près ;-)
Attacks against TLS/SSL (Wikipédia)
Non, vous n'êtes pas sauvés. D'abord parce que plein de bases de données stockent les mots de passe en clair, et de plus les données récupérées en mémoire peuvent contenir le login / mot de passe que vous êtes en train d'envoyer en HTTP au serveur pour vous loguer, le tout en clair évidemment. De plus, ces données peuvent contenir un cookie de session qui permet à l'assaillant de se loguer avec un compte ; imaginez que ce soit le compte du superadministrateur du site ! Là, c'est la fête.
Je viens de découvrir l'émission 14h42, et du coup j'en ai visionné plusieurs, je les trouve toutes passionnantes, notamment la dernière, on se sent moins bête après qu'avant... Donc bravo !
Je ne suis qu'étudiant en dernière année d'école d'informatique, et pour avoir déjà utilisé souvent la librairie OpenSSL, une chose me parait une chose plutot évidente :
OpenSSL est une librairie de cryptage utilisée par le serveur. Pour acceder à une supposée faille OpenSSL, il faut d'abord faire passer son paquet de données biaisé par le serveur lui même, non ? C'est à dire que le serveur peut tres facilement détecter la taille malhonnête demandée par la requete avant d'y répondre.
OpenSSL n'est jamais directement en contact avec les requetes du hacker. De fait je continue de ne pas comprendre la faille. Si quelqu'un peut m'éclairer.
OpenSSL est une librairie de cryptage utilisée par le serveur. Pour acceder à une supposée faille OpenSSL, il faut d'abord faire passer son paquet de données biaisé par le serveur lui même, non ? C'est à dire que le serveur peut tres facilement détecter la taille malhonnête demandée par la requete avant d'y répondre.
OpenSSL n'est jamais directement en contact avec les requetes du hacker. De fait je continue de ne pas comprendre la faille. Si quelqu'un peut m'éclairer.
Au vu du nombre de commentaires, les asinautes n'ont pas cédé à la psychose du cœur qui saigne.
