Libgcrypt 1.7.8 bouche une faille permettant de récupérer une clé RSA sur 1024 bits

Libgcrypt 1.7.8 bouche une faille permettant de récupérer une clé RSA sur 1024 bits

L'été sera chaud !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

04/07/2017 2 minutes
32

Libgcrypt 1.7.8 bouche une faille permettant de récupérer une clé RSA sur 1024 bits

Libgcrypt est victime d'une faille de sécurité qui permet de récupérer une clé de chiffrement RSA sur 1024 bits, et laisse entrevoir une attaque similaire sur 2048 bits. Une mise à jour est disponible, reste maintenant à ce qu'elle soit implémentée par les systèmes utilisant cette bibliothèque.

Une mise à jour importante a été publiée pour la bibliothèque de cryptographie Libgcrypt. Portant le numéro de version 1.7.8, elle permet de combler la faille identifiée CVE-2017-7526.

Une faille pour RSA-1024, qui pourrait toucher RSA-2048

Elle est importante puisque l'équipe de Debian explique que les chercheurs ont « découvert que Libgcrypt est prédisposé à une attaque par canal auxiliaire locale permettant une récupération complète de clé pour le chiffrement RSA-1024 ». Les chercheurs précisent également que cette attaque pourrait fonctionner sur des clés RSA sur 2048 bits avec une puissance de calcul « modérément plus importante ».

Précisons tout de même que son exploitation nécessite d'avoir accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire. Détail important cependant, dans le cas d'un ordinateur exécutant plusieurs machines virtuelles, « cette attaque peut être utilisée par une VM pour récupérer des clés privées d'une autre VM », ce qui peut être un problème dans le cadre de serveurs par exemple. Tous les détails techniques sont disponibles dans ce document.

Des mises à jour disponibles pour Debian et Ubuntu

Une faille de sécurité dont la portée est augmentée par la très large utilisation de Libgcrypt dans de nombreuses distributions, y compris dans des systèmes propriétaires comme des NAS. Comme toujours, il est recommandé de se mettre à jour dès que possible.

Certaines distributions Linux ont d'ores et déjà déployé des correctifs, c'est notamment le cas de Debian et d'Ubuntu. De son côté Red Hat explique qu'il mène des investigations afin de vérifier ce qu'il en est pour Red Hat Entreprise Linux 5 à 7. D'autres arriveront certainement dans les jours qui viennent.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une faille pour RSA-1024, qui pourrait toucher RSA-2048

Des mises à jour disponibles pour Debian et Ubuntu

Commentaires (32)


RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voir 4096.


Avec ou sans obligation de déclaration ? ( > à 2048)


https://www.nextinpact.com/news/99777-chiffrement-notre-antiseche-pour-expliquer-a-vos-parents.htm



Je te conseille de rechercher le passage qui dit « l’utilisation des moyens de cryptologie est libre »








David_L a écrit :



https://www.nextinpact.com/news/99777-chiffrement-notre-antiseche-pour-expliquer-a-vos-parents.htm



Je te conseille de rechercher le passage qui dit « l’utilisation des moyens de cryptologie est libre »





Pour le moment… :(









jice68 a écrit :



Pour le moment… :(





E. Macron approuve ce message… et veut qu’on lui fournisse “les codes” <img data-src=" />



Plus sérieusement :

https://www.nextinpact.com/news/103575-les-outils-chiffrement-face-a-declaration-a-anssi-exception-francaise.htm

Quand on voit la liste de documents à fournir, tu m’étonnes que c’est une calamité pour les “petits” développeurs









Wikus a écrit :



E. Macron approuve ce message… et veut qu’on lui fournisse “les codes” <img data-src=" />



Plus sérieusement :

https://www.nextinpact.com/news/103575-les-outils-chiffrement-face-a-declaration-a-anssi-exception-francaise.htm

Quand on voit la liste de documents à fournir, tu m’étonnes que c’est une calamité pour les “petits” développeurs





Su Git, personne n’ira vérifier que tu es français. <img data-src=" />









Ricard a écrit :



Su Git, personne n’ira vérifier que tu es français. <img data-src=" />





Je propose de franciser ce nom barbare en “Gîte” <img data-src=" /> :pinard: <img data-src=" />









Ricard a écrit :



RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voire 4096.





(voire, pas “voir”, ça ne concerne pas la vision)

<img data-src=" />



Sinon, la recommandation pour encore plus de 10 ans, c’est 2048 bits pour RSA. Il faut dire que le record de factorisation est à 768 bits et donc on est très très loin des 2048 (même 1024 semble quasi hors de portée sauf à y mettre des moyens énormes).

https://www.keylength.com/fr/5/









Ricard a écrit :



RSA 1024 ? Qui l’utilise encore ?

La norme c’est 3072 maintenant, voir 4096.





Bah, beaucoup de monde en l’occurrence, surtout du 2048.



LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.





jice68 a écrit :



Pour le moment… :(





+1 … Mac n’est pas vraiment aimant pour le chiffrement :/

A quand les échanges secret devenus publiques hors de Wikileaks ? ^^









Ricard a écrit :



Su Git, personne n’ira vérifier que tu es français. <img data-src=" />





Certes <img data-src=" />

On remercie donc Apple d’exiger la déclaration lors de la publication d’un tel soft sur l’AppStore (est-ce toujours le cas ?). ChatSecure, Wire, ProtonMail, cryptomator… ont visiblement été ravis de se frotter à l’administration française !



Thankfully, there is an English website for this.

But the fun stops there. From now on, everything is in French. Yup. That’s right. Everything. Even the responses you receive are in French. And you have to submit your request via mail (yes, not email).

cryptomator









David_L a écrit :



https://www.nextinpact.com/news/99777-chiffrement-notre-antiseche-pour-expliquer-a-vos-parents.htmJe te conseille de rechercher le passage qui dit&nbsp;«&nbsp;l’utilisation des moyens de cryptologie est libre&nbsp;»





J’ai quand même du mal avec le passage du pourquoi chiffrer… Parce que bon :



. Car vous mettez des enveloppes autour de votre courrier : Le facteur peut très bien ouvrir ma lettre ou même un voisin car crocheter une boite c’est vraiment fastoche.

. vous n’affichez pas votre numéro et votre code de carte bancaire sur un t-shirt : Je ne vois pas le rapport

. vous fermez vos portes à clef : 380.000 cambriolage en france chaque année !

. vous envoyez des messages sur Facebook Messenger et pas uniquement via votre mur public : Et alors ? Mon collègue peut très bien aller sur ma tab pendant que je vais boire un café !



Pourquoi vous ne dites pas simplement la vérité les gars !



Si une communication n’est pas chiffrée ont peut ce prendre un man in the middle car 99.99% d’internet n’est pas sécurisé et facilement piratable ( demandez au ukrainiens ), que des fournisseur de mails peuvent très facilement lire vos emails ( en ce logguant sur votre compte de manière invisible ou en sniffant le protocole ), et qu’un gamin de 12 ans peut hacker votre navigateur et pomper toutes vos données en quelques secondes !



C’est des exemple concret qui sont déja arrivés et bien mieux que des argument extrêmes complètement débile et c’est la première chose que mes parent me répondront. Pour résumer ce n’est pas tant les chose à cacher qui pose problème mais la facilité à les découvrir via internet part moyen légal ou non.









the_Grim_Reaper a écrit :



Bah, beaucoup de monde en l’occurrence, surtout du 2048.



LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.





2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.









Wikus a écrit :



Certes <img data-src=" />

On remercie donc Apple d’exiger la déclaration lors de la publication d’un tel soft sur l’AppStore (est-ce toujours le cas ?). ChatSecure, Wire, ProtonMail, cryptomator… ont visiblement été ravis de se frotter à l’administration française !



Thankfully, there is an English website for this.

But the fun stops there. From now on, everything is in French. Yup. That’s right. Everything. Even the responses you receive are in French. And you have to submit your request via mail (yes, not email).

cryptomator





Ben… heureusement que l’appstore d’Apple ne représente que 0.5% des solutions de chiffrement alors.









the_Grim_Reaper a écrit :



Bah, beaucoup de monde en l’occurrence, surtout du 2048.



LE 3072 et 4096 sur beaucoup de liens c’est trop lourd à mettre en place/exploiter.

Après, pour avoir fait des préco de sécu, j’avais regardé sur le RGS ancienne version, et du coup, j’étais parti sur du 4096 pour avoir une dureé de vie des clés assez grande vu la durée de vie des documents chiffrés.





Il ne faut pas trop délirer sur les tailles de clés, là on parle d’attaque par des États, et encore même la NSA n’a pas des moyens illimités, surtout pour aller craquer un de vos documents relativement anodins.









Ricard a écrit :



2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.





Le 1024 n’est pas encore tombé (cf mon lien précédent), tu dois confondre avec une taille bien inférieure.

Pas la peine de se branler la nouille, la différence entre 1024 et 2048 est tout simplement énorme (rien à voir avec 2 fois plus de temps), et le 2048 est hors de portée pour un bout de temps, et on parle encore une fois d’organisations qui auraient des moyens considérables.



De toutes façons, tout dépend de ce qu’on veut protéger : si c’est un document qui n’aura guère d’importance dans 5 ou 10 ans, pas la peine de d’utiliser un marteau-pilon. Perso, je chiffre pour éviter qu’on puisse lire facilement le contenu, et pour ça même du 1024 bits suffirait amplement (qui va aller faire tourner des réseaux entiers de machines + l’électricité associée pour aller déchiffrer une archive “tgz” ?).



Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).








127.0.0.1 a écrit :



Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).





<img data-src=" />









127.0.0.1 a écrit :



Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).





Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire.&nbsp;









127.0.0.1 a écrit :



Du moins, tous les derniers guides/tutos que j’ai lu sur les outils de crypto utilisent RSA 4096, AES 256 et SHA 256 (voir SHA 512).





C’est vraiment pour se la jouer, parce que c’est assez inutile pour le commun des mortels (et ça a un coût).









David_L a écrit :



Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire.







Certes. Reste à espérer que ces solutions low-power ne soient pas visées par l’exploitation de cette faille.



Mais si c’est du low-power, c’est sans doute un système dédié (NAS ?, middleware réseau ?). Et on peut espérer qu’il n’y ait pas un “accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire”. <img data-src=" />









OlivierJ a écrit :



Il ne faut pas trop délirer sur les tailles de clés, là on parle d’attaque par des États, et encore même la NSA n’a pas des moyens illimités, surtout pour aller craquer un de vos documents relativement anodins.





Le 1024 n’est pas encore tombé (cf mon lien précédent), tu dois confondre avec une taille bien inférieure.

Pas la peine de se branler la nouille, la différence entre 1024 et 2048 est tout simplement énorme (rien à voir avec 2 fois plus de temps), et le 2048 est hors de portée pour un bout de temps, et on parle encore une fois d’organisations qui auraient des moyens considérables.



De toutes façons, tout dépend de ce qu’on veut protéger : si c’est un document qui n’aura guère d’importance dans 5 ou 10 ans, pas la peine de d’utiliser un marteau-pilon. Perso, je chiffre pour éviter qu’on puisse lire facilement le contenu, et pour ça même du 1024 bits suffirait amplement (qui va aller faire tourner des réseaux entiers de machines + l’électricité associée pour aller déchiffrer une archive “tgz” ?).





La puissance de calcul n’est plus si énorme avec le cloud et le GPGPU ;) mets toi à la page des algo et des puissances louable sur Azure et EC3…

La clé de 1024 est tombée y’a des années, c’est assez vite après celle de 768 bits justement.

C’est en grande partie pour ca que RSA a fini par annulé son concourt de cassage de clés :p



Le 2048 n’est pas hors de portée avec les machines actuelles, sans compter la recherche quantique.

De plus, je n’ai fait que suivre les recommandation de l’ANSSI (une bande de branleurs d’après toi) qui recommande d’aller au dela de 2048 pour des documents échangés au delà de 2019 (ce qui était mon cas) dans le cas d’un chiffrement asymétrique.



Après, pour juger des doc que j’avais à protéger, je pense que je suis plus à même que toi de savoir.

En l’occurrence, c’est pour plus de 10 ans, avec des données confidentielles (industrielle et personnelles clients) .



C’est beau de faire des remarques déplacées, encore faut-il un minimum maîtriser son sujet, ce qui ne semble pas vraiment être le cas ici, et prendre en compte les contraintes d’utilisation des autres.

Avec des gens comme toi, je ne m’étonnerai pas de voir des données perso se balader dans al nature <img data-src=" />





Ricard a écrit :



2048 minimum en effet. C’est pour ça que j’ai dit 3072 pour une bonne sécurité.

Le 1024 est tombé il y a 7 ans maintenant avec peu de moyens à l’époque (80 pentiums pendant 3 mois). Perso, vu les moyens actuels de certaines agences/botnets/whatever, le 2048 me fait plus trop confiance.





Ete 2010 de mémoire en plus ;)



Visiblement, quelqu’un n’est pas d’accord avec nous…

Et de surcroît, se permet de faire des remarques sans connaitre le contexte autour.



Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.









David_L a écrit :



Vrai pour les tutos emails & co, quand tu dois implémenter ça dans des solutions avec peu de puissance & co, c’est un autre délire.





BAh, si le compte sert à chiffrer des docs en plus des mails, c’est pas forcément déconnant.

Si c’est juste pour du chiffrement mails, effectivement…





127.0.0.1 a écrit :



Certes. Reste à espérer que ces solutions low-power ne soient pas visées par l’exploitation de cette faille.



Mais si c’est du low-power, c’est sans doute un système dédié (NAS ?, middleware réseau ?). Et on peut espérer qu’il n’y ait pas un “accès à la machine et pouvoir y exécuter des logiciels de manière arbitraire”. <img data-src=" />





Le soucis des mots de passes faible, tu l’as aussi dans le monde de l’industrie et services :/









the_Grim_Reaper a écrit :



BAh, si le compte sert à chiffrer des docs en plus des mails, c’est pas forcément déconnant.

Si c’est juste pour du chiffrement mails, effectivement…



Le soucis des mots de passes faible, tu l’as aussi dans le monde de l’industrie et services :/





RSA sert aussi dans TLS… Rien que ça.<img data-src=" />

Quand on sait que sur Nxi c’est du RSA 256. <img data-src=" />









the_Grim_Reaper a écrit :



Ete 2010 de mémoire en plus ;)



Visiblement, quelqu’un n’est pas d’accord avec nous…

Et de surcroît, se permet de faire des remarques sans connaitre le contexte autour.



Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.





En mars 2010 exactement. Par les chercheurs de l’Univesité du Michigan.

http://ns.umich.edu/new/releases/7551

et le PDF qui va bien:http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf









the_Grim_Reaper a écrit :



La puissance de calcul n’est plus si énorme avec le cloud et le GPGPU ;) mets toi à la page des algo et des puissances louable sur Azure et EC3…





Avant de pouvoir louer de quoi casser du RSA facilement, je te conseille de gagner au loto d’abord.

Et puis qui va louer un réseau entier de machines puissantes pour aller casser tes documents, simple individu ?







the_Grim_Reaper a écrit :



La clé de 1024 est tombée y’a des années, c’est assez vite après celle de 768 bits justement.

C’est en grande partie pour ca que RSA a fini par annulé son concourt de cassage de clés :p





Le cassage de la clé de 1024 s’appuyait sur un méthode indirecte (effet sur la consommation du processeur), qui peut être corrigée (et l’a été dans les circuits spécialisés, d’ailleurs dans les cartes à puces - ou circuit utilisant du RSA - en principe c’est le cas) :http://macbidouille.com/news/2010/03/08/des-chercheurs-ont-reussi-a-casser-une-c…



Pour info j’ai aussi bossé chez Schlumberger (partie qui est devenu Gemalto) dans la partie cartes à puces, je ne pars pas de zéro.







the_Grim_Reaper a écrit :



Le 2048 n’est pas hors de portée avec les machines actuelles, sans compter la recherche quantique.





La recherche quantique, si ça aboutit, c’est même pas 4096 bits qui vont te protéger, il me semble.

Quand aux 2048 bits, le saut est gigantesque. Un ordre de grandeur expliqué ici par exemple :http://www.bibmath.net/forums/viewtopic.php?id=6389 .







the_Grim_Reaper a écrit :



De plus, je n’ai fait que suivre les recommandation de l’ANSSI (une bande de branleurs d’après toi) qui recommande d’aller au dela de 2048 pour des documents échangés au delà de 2019 (ce qui était mon cas) dans le cas d’un chiffrement asymétrique.





“une bande de branleurs d’après toi” : ?? Où j’aurais écrit ça <img data-src=" />

Quand j’ai mentionn” l’ANSSI dans un commentaire précédent, j’ai indiqué ce lienhttps://www.keylength.com/fr/5/ dans lequel il est indiqué :

2014-2020 : symétrique : 100 bit | asymétrique factorisation : 2048 bits

2021-2030 : symétrique : 128 bit | asymétrique factorisation : 2048 bits



Et ça s’adresse plus à des banques et des institutions étatiques qu’à de simples individus, qui détiennent rarement des informations du même intérêt.







the_Grim_Reaper a écrit :



Après, pour juger des doc que j’avais à protéger, je pense que je suis plus à même que toi de savoir.

En l’occurrence, c’est pour plus de 10 ans, avec des données confidentielles (industrielle et personnelles clients).





Ben si tu veux te faire plaisir avec 4096 bits ou 8192 bits, éclate-toi hein. On va pas te gâcher le plaisir.







the_Grim_Reaper a écrit :



C’est beau de faire des remarques déplacées, encore faut-il un minimum maîtriser son sujet





Mouais. Relis.







the_Grim_Reaper a écrit :



Tout le monde ne bosse pas pour une PME du BTP qui est spécialisée dans le goudronnage de route.





Des grosses boîtes surtout, avec des besoins de protection aussi.









Ricard a écrit :



RSA sert aussi dans TLS… Rien que ça.<img data-src=" />

Quand on sait que sur Nxi c’est du RSA 256. <img data-src=" />





Bah en TLS y’a pas vraiment beaucoup mieux si tu ne veut pas planter les perfs, sauf à investir dans un accélérateur à côté de mémoire. Ca fait un moment que j’ai aps fait de pur technique sécu réseau.

Mais le coût n’est pas le même.





Ricard a écrit :



En mars 2010 exactement. Par les chercheurs de l’Univesité du Michigan.

http://ns.umich.edu/new/releases/7551

et le PDF qui va bien:http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf





My (Wo)man, merci :)





OlivierJ a écrit :



Avant de pouvoir louer de quoi casser du RSA facilement, je te conseille de gagner au loto d’abord.

Et puis qui va louer un réseau entier de machines puissantes pour aller casser tes documents, simple individu ?





Le cassage de la clé de 1024 s’appuyant sur un méthode indirecte (effet sur la consommation du processeur), qui peut être corrigée (et l’a été dans les circuits spécialisés, d’ailleurs dans les cartes à puces - ou circuit utilisant du RSA - en principe c’est le cas) :http://macbidouille.com/news/2010/03/08/des-chercheurs-ont-reussi-a-casser-une-c…



Pour info j’ai aussi bossé chez Schlumberger (partie qui est devenu Gemalto) dans la partie cartes à puces, je ne pars pas de zéro.





La recherche quantique, si ça aboutit, c’est même pas 4096 bits qui vont te protéger, il me semble.

Quand aux 2048 bits, le saut est gigantesque. Un ordre de grandeur expliqué ici par exemple :http://www.bibmath.net/forums/viewtopic.php?id=6389 .





“une bande de branleurs d’après toi” : ?? Où j’aurais écrit ça <img data-src=" />

Quand j’ai mentionn” l’ANSSI dans un commentaire précédent, j’ai indiqué ce lienhttps://www.keylength.com/fr/5/ dans lequel il est indiqué :

2014-2020 : symétrique : 100 bit | asymétrique factorisation : 2048 bits

2021-2030 : symétrique : 128 bit | asymétrique factorisation : 2048 bits



Et ça s’adresse plus à des banques et des institutions étatiques qu’à de simples individus, qui détiennent rarement des informations du même intérêt.





Ben si tu veux te faire plaisir avec 4096 bits ou 8192 bits, éclate-toi hein. On va pas te gâcher le plaisir.





Mouais. Relis.





Des grosses boîtes surtout, avec des besoins de protection aussi.





Bah.. Azure ou EC3, tout le monde peu en louer, donc oui… :p

Et le prix de la puissance de calcul est ridicule. Encore une fois, renseignes-toi avant de sortir des choses.



Vive le site de référence… <img data-src=" />



Si tu passe en quantique, tous les algo actuels vont tomber. Pour le coup, le nombre de clients est assez limité actuellement. Etats et grosses société (couple Google-Nasa).

Du coup, y’a déjà de la recherche pour pondre un algo quantique.



Bah, vu que dans mon post initial je précise que je me suis basé sur les recommandations du RJS V1 (comme précisé, les V2 n’étaient alors pas dispo), je me dis que… soit t’as pas vu … soit tu ‘en cognes.

Je viens de vérifier, pour la V2, c’est du 2048. My bad, vive la regression de la V2 :/



Ne sachant pas où je bossais (et à quel poste) et où je bosse maintenant… posé la question aurait été totalement pertinente ;)

Et vu qu’a tour de rôle j’ai fait les deux, c’est balo ;)



C’est surtout parce que j’ai anticipé les lourdeurs organisationnelles autour ;)

En soit, le temps passé à généré la clé est un poil plus long, mais c’est pas mortel non plus. A l’usage ça ne changeait rien :)



Bah justement.



Miracle… enfin un post avec des choses constructives et posée :)

Y’a donc, les grosses boites (tous secteurs confondus), les administrations, les banques, et les prestataires associés (beaucoup d’externalisation dans tout ça).









the_Grim_Reaper a écrit :



Bah en TLS y’a pas vraiment beaucoup mieux si tu ne veut pas planter les perfs, sauf à investir dans un accélérateur à côté de mémoire. Ca fait un moment que j’ai aps fait de pur technique sécu réseau.

Mais le coût n’est pas le même.





Certes. Mais il y a TLS et TLS. TLS 1.0, c’est de la merde.

Seul TLS 1.2 tient la route.

Bon après je disais Nxi, comme ça mais il y a pire. Le site du Crédit Agricole est encore plus pourri, et pire que tout, le site des impôts (interface de connexion) ou tu rentres tes logins mdp utilise du DES3. Je te laisse deviner ce qu’il se passe si Mme Michu doit faire sa déclaration avec son XP IE6. Sécurité = 0



Ça veut dire que quelqu’un pourrait payer à ma place ? <img data-src=" />







<img data-src=" />


Ou déclarer tes tableaux de maître et résidences secondaires à ta place. :)








Ricard a écrit :



Certes. Mais il y a TLS et TLS. TLS 1.0, c’est de la merde.

Seul TLS 1.2 tient la route.

Bon après je disais Nxi, comme ça mais il y a pire. Le site du Crédit Agricole est encore plus pourri, et pire que tout, le site des impôts (interface de connexion) ou tu rentres tes logins mdp utilise du DES3. Je te laisse deviner ce qu’il se passe si Mme Michu doit faire sa déclaration avec son XP IE6. Sécurité = 0





:lol:









Z-os a écrit :



Ou déclarer tes tableaux de maître et résidences secondaires à ta place. :)





:laurent_fabius:



Ce n’est pas plus lourd à ma connaissance (du moins, ça ne se ressent pas réellement), Google et d’autres entreprises recommandent déjà de passer tout le web en HTTPS même si “y’en a pas besoin”:



-https://https.cio.gov/everything/

-https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite

-https://www.sslshopper.com/why-ssl-the-purpose-of-using-ssl-certificates.html



Ça fait un moment que j’ai pas lu ces liens mais Google semblait dire qu’en passant toute leur infra en HTTPS ils s’attendaient à une montée de la charge. Elle l’a été de moins d’1% et donc leur préparation n’a été qu’une précaution en fin de compte.

&nbsp;

Je sais que je dépose ces liens à l’arrache mais ils m’ont convaincu qu’ils fallait tout passer en HTTPS, et de toute façon mes clés sont toutes en 4096 donc cette faille ne semble pas me concerner o.

&nbsp;








koshieDotFr a écrit :



Je sais que je dépose ces liens à l’arrache mais ils m’ont convaincu qu’ils fallait tout passer en HTTPS, et de toute façon mes clés sont toutes en 4096 donc cette faille ne semble pas me concerner o.





Ben t’es juste concerné quand tu navigues sur INternet sur un site qu’a une sécurité moisie avec un navigateur moisi. Ca concerne beaucoup de monde, sans parler qu’un certificat qui serait “compromis” est toujours valable, même dans un navigateur récent, sans que tu le saches.

Mais ça, malheureusement, tu n’y peux rien.<img data-src=" />