Cidrolin 22 avril 2014 à 13:25
[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.

Cidrolin 22 avril 2014 à 11:10
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é* !

HerrThomas 18 avril 2014 à 20:27
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".

Compte supprimé à la demande de l'utilisateur 18 avril 2014 à 18:55

Ce message a été supprimé suite à la suppression du compte de son auteur

Mangematin 18 avril 2014 à 12:01
... Roohhh ! On ne dit pas "Eurtblid" mais "Heartbleed" > Heart = coeur = [hart]

http://commons.wikimedia.org/w/index.php?title=File%3AEn-uk-heart.ogg

Hervé Masson 18 avril 2014 à 04:47
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.

OuvreBoîte 17 avril 2014 à 22:56
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.

joyeux 17 avril 2014 à 11:03
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 !

Merle 17 avril 2014 à 08:39
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).

Merle 17 avril 2014 à 08:13
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.

tchd 16 avril 2014 à 22:34
Au vu du nombre de commentaires, les asinautes n'ont pas cédé à la psychose du cœur qui saigne.