Heartbleed, OpenSSL et la question de la sécurité expliqués simplement
Quatre questions, quatre réponses
Le 09 avril 2014 à 10h00
13 min
Internet
Internet
Lundi soir, une faille importante était annoncée au sein d'OpenSSL. Comme nous l'avions évoqué hier, celle-ci pourrait avoir des conséquences assez graves, mais elle n'a pour autant pas soulevé de grandes réactions en France, bien que la presse semble commencer à s'en emparer. Devant le besoin de pédagogie sur une question aussi complexe, nous avons décidé de tenter de la rendre compréhensible au plus grand nombre en répondant à quelques questions claires.
Depuis lundi soir, le hashtag #Heartbleed semble affoler de plus en plus de monde. Au départ ils n'étaient que quelques administrateurs système, mais au fur et à mesure des billets et des articles évoquant le sujet, l'ampleur va en grandissant. En France, cela n'a pas tout de suite été le cas, et l'on notait encore ce matin de nombreux sites d'information qui n'en avaient toujours pas parlé, ce qui devrait aller mieux suite à la publication d'une dépêche AFP. D'autres ne s'étaient toujours pas prémunis contre cette faille béante, qui pourrait pourtant avoir de graves conséquences. Une situation assez bien résumée en un tweet de Stéphane Bortzmeyer publié hier :
"Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-être avez-vous mal évalué la situation" #HeartBleed
— Stéphane Bortzmeyer (@bortzmeyer) 8 Avril 2014
Nous avons donc décidé de résumer tout ce qu'il faut savoir afin de comprendre le sujet, pouvoir en parler autour de vous et sensibiliser votre entourage, en attendant que les choses se tassent et que la majorité des sociétés concernées ne réagisse publiquement, sans doute dans la journée ou les jours à venir. Il sera alors temps de faire le point sur les conséquences exactes.
Heartbleed, c'est quoi ?
Comme nous l'expliquions hier, Heartbleed est une faille dévoilée hier au sein d'une extension d'OpenSSL. Cet outil open source est assez largement utilisé sur internet afin de sécuriser les communications entre votre ordinateur et un serveur. C'est le fameux cadenas dont on vous dit qu'il est nécessaire pour s'assurer de votre sécurité, notamment dans le cadre d'un paiement en ligne. Ce n'est pas le seul service de ce genre qui existe, mais il est très largement exploité, y compris par des sites de vente en ligne, des banques, etc.
Il est capable grâce à l'extension Heartbeat de créer une communication dite de longue durée (détaillée ici). Pour cela, votre machine et le serveur s'envoient de petits messages réguliers pour s'assurer qu'ils sont toujours en contact. C'est cela les fameux battements de cœur dont il est question et qui ont donné naissance au nom et au logo de la faille :
Heartbleed, un nom et un logo bien trouvés
Malheureusement, depuis OpenSSL 1.0.1, introduit en 2012, un bug permet à n'importe qui d'aller lire aléatoirement de petites quantités (jusqu'à 64 ko) de données non chiffrées, stockées dans la mémoire serveur auquel vous êtes connecté, et cela, via une simple requête. Celui-ci n'a été corrigé que hier avec la version 1.0.1 g, et tous les sites touchés doivent se mettre à jour et redémarrer les services qui utilisaient OpenSSL afin de combler cette faille. Ceux qui utilisaient une version antérieure ne sont pas concernés, une prochaine bêta de la branche 1.0.2 fera de même.
Un doute existe quant à la possibilité que les clefs privées qui permettraient de déchiffrer les échanges aient pu être récupérées. Il est donc conseillé d'en générer de nouvelles pour ceux qui gèrent des serveurs exploitant OpenSSL. Si cela était confirmé, cela voudrait dire que n'importe quel échange chiffré récupéré par un tiers ces dernières années, pourra désormais être lu en clair. C'est un point qui a spécifiquement fait réagir l'Electronic Frontier Foundation (EFF) qui appelle à une utilisation plus massive d'une couche de sécurité supplémentaire : Perfect Forward Secrecy.
Si un site est indiqué comme vulnérable, dois-je m'en méfier ?
Comme l'on pouvait s'y attendre, de très nombreux sites ont été touchés, parfois même certains géants du web. Un outil qui permet de tester un domaine en particulier a été mis en ligne, et selon nos constatations, on peut trouver des données sensibles dans de nombreux cas, même sur des sites français. Hier, une liste complète avait été mise en ligne, dans la soirée, on trouvait encore de nombreux exemples de sites vulnérables chez nous que nous avons vérifié : CuisineAZ, Castorama, Elle, Europe 1, Millenium, Paris.fr, Premiere, Slate, et Sports.fr.
Mais ce qu'il faut bien comprendre, c'est que ce n'est pas parce qu'un site est indiqué comme vulnérable que des données sensibles peuvent être récupérées. Nous avons par exemple contacté Slate hier pour leur indiquer suite à leur article qu'ils étaient eux-mêmes touchés, mais ils nous ont confirmé qu'ils n'utilisaient pas OpenSSL dans la pratique. Et effectivement, assez peu de données pouvaient être récupérées, aucune n'étant sensible.
Dans la majorité des cas, on retrouve en effet uniquement le code source des pages visitées par les utilisateurs, ce qui n'a rien de vraiment gênant puisque ces pages sont en générales publiques.
@David_NXi @FradiFrad On est vulnérable mais on utilise pas, donc... Par contre, astreinte car c'est bien une soirée pour les script kiddies
— greg ossito (@gregossito) 8 Avril 2014
Cela devient par contre problématique lorsqu'un site vous permet d'échanger avec lui des informations importantes dans un environnement sécurisé. Il y a notamment deux cas qui posent soucis : celui des identifiants de connexion et des cookies, mais aussi celui des données données relatives à un service bancaire. Et des cas assez graves ont été relevés.
Désormais, une majorité de sites ont été patchés, surtout ceux qui contenaient des informations sensibles. Le mieux est néanmoins d'attendre encore quelques jours avant de vous reconnecter, et de modifier vos mots de passe d'ici là. Faites aussi très attention aux mails que vous allez recevoir dans les mois à venir afin d'éviter les tentatives de Phishing. D'ailleurs, ne donnez JAMAIS aucun élément de sécurité à un tiers, même sur un site ressemblant à celui de votre banque ou d'un service quelconque sans vous être assuré de sa véracité, notamment de celle de l'adresse de la page sur laquelle vous vous trouvez.
La gendarmerie a mis en ligne une page explicative avec des contacts à utiliser en cas de problème. Vous pourrez aussi effectuer un signalement via la plateforme Pharos ainsi que sur phishing initiative.
Mes identifiants de connexion sont-ils en danger ?
Il y a de fortes chances que oui, mais ce n'est pas systématique. Il faut en effet savoir que dans une phase de connexion, la majorité des sites utilise un système assez simple, et les procédures réellement sécurisées sont rares. Le cas le plus courant est de voir un site vous demander votre pseudonyme ou votre email, ainsi que votre mot de passe. Ceux-ci sont envoyés au serveur qui va ensuite les vérifier. Et dans la majorité des cas, tout ceci se passe sans aucun chiffrement. En effet, vos éléments de sécurité transitent en clair sur le réseau, c'est notamment pour cela qu'il est souvent recommandé de ne pas se connecter à certains sites si vous êtes sur un réseau Wi-Fi public. C'est aussi notamment pour cela que nous avons récemment décidé de revoir notre procédure de connexion à l'occasion de l'introduction de notre système unifié.
Les plus attentifs aux questions de sécurité pourront s'étonner : Pourquoi le « hash » du mot de passe, une variable qui permet de vérifier sa véracité mais qui ne permet (normalement) pas de le retrouver, n'est-il pas calculé puis envoyé au serveur ? Tout d'abord, cela ne ferait que déporter le problème, puisque le hash suffirait alors pour faire croire à une identification réelle. En fait, il y a une raison principale, bien que d'autres éléments plus techniques y participent aussi : pour des raisons de sécurité mises en lumière par plusieurs piratages récents, le calcul n'est pas effectué sur votre machine puisqu'il nécessite une composante aléatoire qui ne doit être connue que du serveur : le « salt ». Cela renforce la sécurité du hash et réduit les chances de pouvoir l'utiliser afin de retrouver le mot de passe de l'utilisateur. Le mot de passe est donc envoyé au serveur, le hash est calculé avec la composante aléatoire, et le tout est vérifié afin de savoir si l'utilisateur peut ou non se connecter.
Idéalement, donc, tous les sites devraient utiliser une connexion sécurisée pour l'échange de ces données, mais ce n'est pas le cas. Ici, ils ont néanmoins été sauvés puisque n'utilisant pas de chiffrement, ils n'ont pas risqué de se retrouver face à une faille du système de chiffrement. D'autres ont par contre été touchés et cela peut avoir des incidences graves.
Le dernier point à aborder pour la question de la connexion est celui des cookies de session. En effet, une fois connecté, le site place un petit fichier dans votre machine afin de vous éviter de vous reconnecter à chaque visite : un cookie. Ceux-ci peuvent aussi dans certains cas être récupérés et recrées par un attaquant qui pourra ainsi se connecter à votre place, même sans connaître vos identifiants. Là aussi il s'agit d'un problème grave, notamment lorsque des éléments importants sont indiqué dans les comptes des utilisateurs.
DO NOT login to http://t.co/Cy7atsRLqT /at all/. Heartbleed hasn’t been fixed, your password can easily be exposed. pic.twitter.com/f3nofmxrLO
— James Long (@ac3xx) 8 Avril 2014
Yahoo! a par exemple été assez vite repéré puisque des relevés ont montré que des mots de passe pouvaient être récupérés via cette faille. La société n'a communiqué que tardivement et discrètement sur le sujet et a mis à jour l'ensemble de ses serveurs dans la fin de journée d'hier. LastPass a par contre communiqué assez ouvertement, comme de nombreux autres, et a indiqué que sa procédure était un peu plus sécurisée que la moyenne, mais que la potentielle fuite des clefs privées pouvait être un problème. La société a de son côté mis en ligne un site permettant de savoir si un site pouvait être touché et de quand datait le certificat utilisé pour le chiffrement, ce qui permet de savoir si il a récemment été renouvellé ou non.
Un autre cas relevé est celui de Darty. Si le domaine principal du revendeur est touché, ce n'est pas le seul. Et celui qui gère la sécurité de la connexion des membres l'est aussi. C'est encore le cas à l'heure où nous écrivons ces lignes et nous avons pu récupérer des identifiants / mot de passe en quelques minutes. Si vous êtes client de l'enseigne et que vous vous êtes connecté récemment, changez donc au plus vite vos mots de passe sur tous vos autres services en attendant qu'elle ne corrige cette faille. Pour le moment, il nous a simplement été indiqué que ses équipes étaient alertées et travaillaient à la résolution du souci, qui n'est toujours pas corrigé :
@David_NXi Bonjour, nos équipes techniques sont informées du point, merci de votre alerte
— Darty (@Darty_Officiel) 9 Avril 2014
Dois-je m'inquiéter pour ma carte bleue et l'accès à mes comptes ?
L'autre cas sensible est celui des services bancaires. Là, deux points sont à surveiller : le premier concerne la connexion à vos comptes en ligne. Certains services ont été touchés, mais tout semble désormais corrigé. Si vous vous êtes connectés à votre compte dans les deux jours qui viennent de s'écouler, il est donc préférable de chercher à changer de mot de passe par sécurité. Nous avons contacté de nombreux organismes afin qu'ils nous confirment s'ils ont été concernés ou pas et quelles sont les procédures mises en place pour leurs clients. Des associations telles que l'AFUB ou l'UFC Que Choisir devraient d'ailleurs assez rapidement s'emparer du sujet.
L'autre problème concerne les systèmes de paiement en ligne utilisés par les sites de vente. Car oui, certains ont été touchés. C'est notamment le cas de celui du groupe CIC / Crédit Mutuel. D'après nos relevés, certains domaines du groupes étaient vulnérables, mais cela a été ensuite résorbé. Dans le cas du Crédit Mutuel par exemple, tout est rentré dans l'ordre ce matin. C'est ce qui nous a poussés à couper l'accès à nos abonnements puis à le réouvrir dans la matinée. Le site Capitaine Train a d'ailleurs fait de même, ou a plutôt opté pour le service Paybox en attendant que le prestataire de la banque soit mis à jour.
Le système de paiement du Crédit Mutuel était vulnérable jusqu'à ce matin, vers 8 h
Pour autant, est-ce que votre numéro de carte bleue est en danger ? Nous n'avons pas trouvé de trace confirmant que de telles informations avaient pu être récupérées en clair. Cela ne veut pas dire que cela n'a pas été le cas, mais nous ne pouvons pas l'affirmer. Là aussi nous avons interrogé les banques pour en savoir plus, et l'on devrait apprendre de nombreux détails avec le recul.
D'après nos constatations, un attaquant pouvait néanmoins récupérer de nombreuses informations : l'e-mail d'un acheteur, le site où il a effectué son achat, le montant de la transaction, etc. Bref, dans le meilleur des cas, tout ce qu'il faut pour lancer une bonne campagne de phishing. Là aussi donc, soyez prudent sur les emails que vous allez recevoir dans les mois à venir, et surveiller vos comptes : en cas de problème, prévenez immédiatement votre banque, qui se doit d'agir.
Bien entendu, de nombreux nouveaux éléments vont arriver sur le sujet dans les jours à venir. Nous n'hésiterons pas à faire des points réguliers et à mettre à jour cette actualité si nécessaire. En attendant, si vous avez la moindre question, n'hésitez pas à la poser au sein de nos commentaires, cela pourra éventuellement nous aider à compléter cet article.
Heartbleed, OpenSSL et la question de la sécurité expliqués simplement
-
Heartbleed, c'est quoi ?
-
Si un site est indiqué comme vulnérable, dois-je m'en méfier ?
-
Mes identifiants de connexion sont-ils en danger ?
-
Dois-je m'inquiéter pour ma carte bleue et l'accès à mes comptes ?
Commentaires (196)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 09/04/2014 à 10h47
Je ne comprends vraiment pas ce point là.
Si la faille existe depuis 2012, pourquoi ne s’inquiéter que pour les deux derniers jours de connexion ?
A part la connaissance du problème qui a été mis en lumière, et as donc multiplié les risque de compromission.
Mais, c’est si on a fait de l’interner depuis 2012 qui est un facteur de risque.
Est ce que quelqu’un a une meilleure explication ?
Le 09/04/2014 à 10h52
Le 09/04/2014 à 10h54
Le 09/04/2014 à 10h55
Le 09/04/2014 à 10h57
C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.
Et que le code avait était relu pour plein de monde.
Et personne a vu la faille à ce moment là…il a du être bien relu le code " />
Le 09/04/2014 à 10h58
Le 09/04/2014 à 10h58
Le 09/04/2014 à 10h59
Le 09/04/2014 à 11h02
Le 09/04/2014 à 11h02
Le 09/04/2014 à 11h03
Le 09/04/2014 à 11h03
Le 09/04/2014 à 11h03
Le 09/04/2014 à 11h06
Le 09/04/2014 à 11h06
Le 09/04/2014 à 11h06
Le 10/04/2014 à 11h30
Le 10/04/2014 à 11h41
Le 10/04/2014 à 11h47
Le 10/04/2014 à 15h23
Le 10/04/2014 à 17h50
puisqu’il nécessite une composante aléatoire qui ne doit être connue que du serveur : le « salt ».
Si je dis pas de conneries, en théorie le hash, le salt, la méthode de hashage, tout ça pourrait être public sans pour autant rendre le mot de passe vulnérable.
Bien sûr ça dépend du mot de passe, la première chose qu’un attaquant va faire étant une recherche par dictionnaire et si le mdp s’y trouve…
C’est bien pour ça qu’on préconise un bon mot de passe, càd un mot de passe long avec des caractères spéciaux.
évidemment l’idéal c’est un bon salt (càd très long et donc pas sur 32 bits…), une méthode de hashage bien lente et un mdp bien long avec des caractères non basiques.
Pour moi le salt ne sert qu’a éviter les rainbow tables, ou tables en tout genre.
Le 10/04/2014 à 18h29
Le 10/04/2014 à 20h05
Le 10/04/2014 à 20h20
Le 10/04/2014 à 20h31
Le 11/04/2014 à 10h38
Le 11/04/2014 à 19h06
Le 09/04/2014 à 11h20
Le 09/04/2014 à 11h24
Le 09/04/2014 à 11h24
Le 09/04/2014 à 11h25
Le 09/04/2014 à 11h27
Concernant le paragraphe sur l’identification.
Pourquoi ne pas envoyer le pass hashé au serveur qui se chargera de le hasher à nouveau, mais en incluant cette fois le salt.
De cette manière, le mot de pass n’est pas transmis en clair et le simple fait d’envoyer le hash “de base” ne valide pas l’identification.
C’est une méthode que j’utilisais il y a quelques temps. (En utilisant du SHA-2)
Le 09/04/2014 à 11h27
C’est fou la mauvaise foi quand même.
Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.
Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…
Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.
Le 09/04/2014 à 11h29
Le 09/04/2014 à 11h29
Le 09/04/2014 à 11h30
Le 09/04/2014 à 11h30
Le 09/04/2014 à 11h31
Le 09/04/2014 à 11h34
Le 09/04/2014 à 11h35
Le 09/04/2014 à 11h35
Le 09/04/2014 à 11h36
Le 09/04/2014 à 11h37
C’est pour ça que j’ai eu des corrections au trot sur ma Mint hier soi et avant-hier soir…
Testé pour vous :
Le 09/04/2014 à 12h23
Le 09/04/2014 à 12h24
Le 09/04/2014 à 12h28
Pour contribuer au débat, on peut remarquer, c’est que le code managé proprio ne protège pas contre les hackers qui ont 5 ans. " />
Le 09/04/2014 à 12h28
Le 09/04/2014 à 12h29
Le 09/04/2014 à 12h31
Le 09/04/2014 à 12h33
Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.
les pirates peuvent récupérer des informations en passant par la mémoire des serveurs de l’ordinateur
" />" />" />
Le 09/04/2014 à 12h34
Le 09/04/2014 à 12h43
Le 09/04/2014 à 12h43
Le 09/04/2014 à 12h46
Le 09/04/2014 à 12h46
Un code source dispo et bien exploité ne permettrait pas d’orienter ses attaques et/ou de mieux détecter les failles ? " />
Le 09/04/2014 à 12h46
Le 09/04/2014 à 12h47
Le 09/04/2014 à 12h47
Le 09/04/2014 à 12h51
Le 09/04/2014 à 13h28
Le 09/04/2014 à 13h31
Le 09/04/2014 à 13h33
Le 09/04/2014 à 13h35
Le 09/04/2014 à 13h38
Quelques compléments techniques" />
Le 09/04/2014 à 13h38
Le 09/04/2014 à 13h43
Le 09/04/2014 à 13h53
Le 09/04/2014 à 13h53
Le 09/04/2014 à 13h54
Le 09/04/2014 à 13h55
Le 09/04/2014 à 13h55
Très bonne news par contre ça serait bien que y’ai une partie un peu moins grand public et que PCInpact sorte du lot de l’info numérique en expliquant concrètement le fonctionnement de la faille.
Le 09/04/2014 à 14h07
Faille présente sur le DSM 5.0 de Synologiy qui ne communique pas sur les failles non corrigées (!) :
Pour protéger les utilisateurs, Synology n’annonce pas publiquement les vulnérabilités de la sécurité jusqu’à ce que les résolutions soient publiquement disponibles ni les détails exacts de l’émission de telles vulnérabilités. Une fois que les résolutions sont disponibles, les vulnérabilités seront annoncées sur le site web officiel de Synology.
Comme si dans le cas présent, cela servait à quelque chose de ne pas communiquer là dessus !
À l’équipe : avec vos contacts privilégiés chez eux, vous pouvez avoir une info sur la date de correction ?
Le 09/04/2014 à 14h07
Le 09/04/2014 à 14h31
Le 09/04/2014 à 14h41
Le 10/04/2014 à 07h46
Le 10/04/2014 à 07h58
Le 10/04/2014 à 08h20
Le 10/04/2014 à 09h01
Le 10/04/2014 à 09h11
Le 10/04/2014 à 09h30
Le 10/04/2014 à 09h34
Le 10/04/2014 à 09h38
Le 10/04/2014 à 09h50
Le 10/04/2014 à 09h55
Le 10/04/2014 à 09h57
Le 10/04/2014 à 09h58
Le 10/04/2014 à 10h06
Le 10/04/2014 à 10h48
Le 10/04/2014 à 11h10
Le 10/04/2014 à 11h24
Le 09/04/2014 à 11h07
Le 09/04/2014 à 11h08
Le 09/04/2014 à 11h08
Quelqu’un aurait un lien vers une analyse bien didactique du truc?
De ce que j’ai lu jusqu’ici la faille permet de récupérer un bloc de 64k de données dont l’emplacement en mémoire m’a l’air non prévisible.
De la à récupérer comme c’est écrit comptes et mot de passe sur n’importe quel serveur web affecté il me semble qu’il y ait un peu de marge (mais je peux me tromper)
Le 09/04/2014 à 11h09
Le 09/04/2014 à 11h09
Le 09/04/2014 à 11h10
Le 09/04/2014 à 11h14
Le 09/04/2014 à 11h15
Le 09/04/2014 à 11h15
Le gros avantage de l’open-source en soit n’est pas le fait qu’il n’y a pas de failles, c’est évident.
Par contre, et on en a encore un bel exemple ici, lorsqu’une faille est découverte, elle est généralement corrigé dans les heures qui suivent, et tout est mis à jour, au niveau des dépôts, très rapidement.
Ici, la faille a été corrigée avant d’être divulguée, et c’est ça, la grande force de l’open-source versus le proprio.
Je ne suis pas contre le proprio, j’en utilise tous les jours (je développe en .net), mais clairement, ici, il s’agit d’un net avantage.
Le 09/04/2014 à 11h17
Le 09/04/2014 à 11h18
Le 09/04/2014 à 11h18
Le 09/04/2014 à 11h19
Le 09/04/2014 à 11h20
Le 09/04/2014 à 11h20
Le 09/04/2014 à 11h20
Le 09/04/2014 à 12h52
Le 09/04/2014 à 12h52
Le 09/04/2014 à 12h54
Le 09/04/2014 à 12h54
Le 09/04/2014 à 12h57
Quel bazar ! " />
Quelqu’un a posé la question mais je n’ai pas vu la réponse : pour les comptes Google (gmail…), Facebook, Hotmail, … faut-il changer de mot de passe ? (sans doute vaut-il mieux …)
Merci
Le 09/04/2014 à 12h58
Le 09/04/2014 à 13h02
Le 09/04/2014 à 13h07
Le 09/04/2014 à 13h07
Nous avons par exemple contacté Slate hier pour leur indiquer suite à leur article qu’ils étaient eux-mêmes touchés, mais ils nous ont confirmé qu’ils n’utilisaient pas OpenSSL dans la pratique.
Comment peuvent-ils être touchés sans utiliser OpenSSL ? " />
Ou alors, HTTPS est dispo sur leur site mais ça ne change rien parce qu’il n’y a pas de comptes utilisateurs et donc pas de login en RAM.
Le 09/04/2014 à 13h14
Je me pose une question quand même.
Les 64 Ko de mémoire renvoyé par le serveur est aléatoire. Comment ça se fait que dans le cas de Yahoo! , le serveur renvoie souvent des login et mot de passe ?
Le nombre d’authentification ? L’implémentation de Yahoo! de la gestion de leur authentification ?
Le 09/04/2014 à 13h14
Le 09/04/2014 à 13h14
Le 09/04/2014 à 13h20
Le 09/04/2014 à 13h20
Le 09/04/2014 à 13h25
Le 09/04/2014 à 13h26
Merci pour les explications, et surtout merci d’utiliser votre position de journalistes spécialisés pour contribuer à faire passer le message le plus largement et rapidement possible.
" />
Le 09/04/2014 à 14h41
Le 09/04/2014 à 14h57
Tor est touché aussi et il recommandé de ne pas l’utiliser pour l’instant
Le 09/04/2014 à 15h01
Le 09/04/2014 à 15h10
Le 09/04/2014 à 15h31
Le 09/04/2014 à 15h43
Le 09/04/2014 à 15h51
Le 09/04/2014 à 16h40
Le 09/04/2014 à 16h45
Le 09/04/2014 à 16h58
Le 09/04/2014 à 17h12
Le 09/04/2014 à 17h12
Le 09/04/2014 à 17h32
Le 09/04/2014 à 18h03
Le 09/04/2014 à 18h35
Le 09/04/2014 à 18h40
Le 09/04/2014 à 18h58
Le 09/04/2014 à 18h58
Le 09/04/2014 à 19h37
Le 09/04/2014 à 19h56
Le 09/04/2014 à 20h18
Le 09/04/2014 à 20h35
Le 09/04/2014 à 20h55
Le 09/04/2014 à 21h08
Le 09/04/2014 à 21h24
Pour un compte yahoo sur lequel je ne me suis pas connecté depuis un moment, il ne faut donc pas que j’y aille pour le moment, ou faut il que j’aille changer le mot de passe justement ?
J’ai un peu de mal là ^^
Merci :)
Le 09/04/2014 à 21h25
Le 09/04/2014 à 21h30
Le 09/04/2014 à 21h38
Le 09/04/2014 à 21h41
Le 09/04/2014 à 22h13
Le 09/04/2014 à 22h44
Le 10/04/2014 à 02h40
Le 09/04/2014 à 10h05
Steam semblerait touché.
Le 09/04/2014 à 10h13
Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !
" />
Le 09/04/2014 à 10h22
Merci pour cette synthèse PCi, heu NEXTi " />
Le 09/04/2014 à 10h31
Donc, si je comprends bien, si on ne s’est pas connecté à un site compromis, il n’y a pas de problème ?
Genre, quelqu’un qui ne se serait pas connecté à Yahoo dans les 2 dernières semaines ne risque pas d’avoir son mot de passe dans la nature.
Le 09/04/2014 à 10h31
A noter que dans les cas de la carte bleue stricto sensu, la loi impose à la banque de prendre en charge toute utilisation frauduleuse des moyens de paiement qu’elle met à votre disposition.
Donc même si vous vous retrouvez victime d’une fraude, la banque doit vous rembourser.
Le 09/04/2014 à 10h31
Donc si j’ai bien compris, si on s’est connecté sur un site vulnérable entre la découverte de la faille et aujourd’hui, il est indispensable de changer le mot de passe. Mais si on ne s’est pas connecté, les risques de piratage sont moindres mais ça n’évite pas le risque zéro.
Le 09/04/2014 à 10h36
Question : si on est toujours co sur ledit site ( et que dont on a jamais fait déco-reco ) il y a risque ou pas ?
Le 09/04/2014 à 10h36
un bug permet à n’importe qui d’aller lire de petites quantités (jusqu’à 64 ko) de données non chiffrées
Heu…64ko de données non chifrées, c’est énorme." />
Le 09/04/2014 à 10h41
Le 09/04/2014 à 10h42
La version bugguée date de 2012, et on coupe les sites depuis hier ? " />
On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?
Le 09/04/2014 à 10h46
http://filippo.io/Heartbleed/#btce.com
bon les markets sont aussi touché ^^ " />
Le 09/04/2014 à 10h46
Le 09/04/2014 à 11h40
Le 09/04/2014 à 11h41
Le 09/04/2014 à 11h42
le plus top c’est que des boites concernées par la faille ne communique même pas en interne sur le sujet
Le 09/04/2014 à 11h43
Ce que j’en ai compris, c’est que c’est une bête erreur de conception sur une nouvelle version de la librairie qui sert de base à open SSL. C’est malheureusement un problème banal, et inévitable.
D’ailleurs, dans le domaine où je travaille, on en a de bons exemples de ce que ce genre de problème peut causer comme dommages…
Le 09/04/2014 à 11h43
Le 09/04/2014 à 11h44
Ceux qui critiquent le comm de Hadoken n’ont pas du lire les commentaires sur les news “la nsa a approché Linus” ou celle sur GNUtls… Faut voir le nombre d’integriste qui t’insultent quand tu leur apprend que l’open source ne protège pas plus des failles… L’open source permet une grande réactivité mais c’est tout…
Mais bon si certains veulent continuer à vivre dans le pays des bisounours, tant mieux pour eux…
Le 09/04/2014 à 11h44
Le 09/04/2014 à 11h44
Le 09/04/2014 à 11h44
Le 09/04/2014 à 11h45
Donc en résumé :
Ca fait que globalement toute donnée sensible a pu être corrompue sur un site “sécurisé”… génial " />
Le 09/04/2014 à 11h46
Le 09/04/2014 à 11h47
Le 09/04/2014 à 11h49
Le 09/04/2014 à 11h50
Le 09/04/2014 à 11h50
Le 09/04/2014 à 11h50
" /> Merci Hadoken et Charon pour cette grosse tranche de rigolade à voir des barbus hurler en ayant mal au cul. " />
Le 09/04/2014 à 11h53
Le 09/04/2014 à 11h53
Le 09/04/2014 à 12h01
Le 09/04/2014 à 12h06
Le 09/04/2014 à 12h07
Je vient de mettre mon raspberry pi sous raspbian à jour " />
(la version d’openssl était apparement vulnérable)
Le 09/04/2014 à 12h09
Le 09/04/2014 à 12h10
Le 09/04/2014 à 12h11
Le 09/04/2014 à 12h11
Le 09/04/2014 à 12h12
Le 09/04/2014 à 12h15
Le 09/04/2014 à 12h18
L’humain étant faillible, toutes ses créations le sont.
Et son génie consiste justement à sublimer sa faillibilité.
C’est ce qui pour moi est le plus intéressant dans cette histoire de sécurité informatique.
“Il y a une faille en tout, c’est comme cela que la lumière rentre” - Leonard COHEN
Le 09/04/2014 à 12h19