Faille FREAK : quand des connexions SSL/TLS se contentent d'un chiffrement RSA sur... 512 bits

Faille FREAK : quand des connexions SSL/TLS se contentent d’un chiffrement RSA sur… 512 bits

Le Freak, c'est chic !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

04/03/2015 6 minutes
71

Faille FREAK : quand des connexions SSL/TLS se contentent d'un chiffrement RSA sur... 512 bits

Après le douloureux épisode HeartBleed d'OpenSSL, le chiffrement des connexions SSL/TLS est une nouvelle fois mis à mal avec FREAK (Factoring RSA EXPORT Attack Keys). Via une attaque de type « homme du milieu », un pirate peut décrypter les échanges de données sécurisées entre un serveur et navigateur web.

Il y a quelques mois, la faille Heartbleed d'OpenSSL faisait largement parler d'elle. Il faut dire que les conséquences pouvaient être fâcheuses puisqu'il était possible d'accéder à des données chiffrées stockées dans la mémoire des serveurs. Plus récemment, c'était au tour de la faille POODLE de SSLv3 de faire les gros titres, et c'est maintenant FREAK qui entre en piste.

FREAK : une attaque basée sur un reliquat des années 90 avec « export RSA »...

Sur leur principe de fonctionnement, les failles POODLE et Freak ne sont pas très éloignées l'une de l'autre. Dans les deux cas, il s'agit en effet d'une attaque de type « homme du milieu » où il faut empêcher autant que possible le navigateur et le serveur de se connecter via un protocole de sécurité récent, et donc normalement plus robuste. Alors que POODLE exigeait une « downgrade dance » pour passer de TLS à SSLv3, FREAK court-circuite la négociation du système de chiffrement qui sera utilisé entre le navigateur et le serveur.

En temps normal, ils se mettent d'accord sur le système de chiffrement le plus fort possible qu'ils prennent tous les deux en charge, et ce, afin d'assurer un maximum de sécurité. Problème, dans certains cas il est possible de forcer un chiffrement relativement faible : « export RSA » qui exploite une clé RSA de 512 bits seulement. Il date des années 90, une période durant laquelle les États-Unis limitaient l'exportation des systèmes de chiffrement à 512 bits maximum. Un palier qui était jugé plus ou moins suffisant pour l'époque, tout en laissant la possibilité aux services de renseignements de décrypter un message si besoin. À titre de comparaison, même le RSA 1024 bits n'est plus jugé comme sécurisé, et on a pu voir Mozilla en supprimer le support dans Firefox 36.

Depuis, cette limitation a été levée, mais « export RSA » continue d'exister dans certains serveurs et navigateurs. C'est notamment le cas de ceux qui utilisent OpenSSL (CVE 2015-0204). Des correctifs sont déjà en ligne depuis le mois de janvier (mais tous les détails n'étaient alors pas dévoilés) et les versions 1.0.1k, 1.0.0p et 0.9.8zd d'OpenSSL corrigent ce souci.

On retrouve également le même problème dans Safari (iOS et OS X) et Apple serait en train de plancher sur une mise à jour selon Reuters, qui cite un porte-parole de la société. Il devrait être proposé aux clients la semaine prochaine, sans plus de détails pour l'instant. Nos confrères se sont également entretenus avec un porte-parole de chez Google qui précise qu'un patch a été développé pour Chrome sur Android et qu'il est proposé aux partenaires du géant du web, sans autres détails sur le calendrier de diffusion.

... et hop la connexion est chiffrée avec une clé de 512 bits seulement

Comme l'expliquent nos confrères de Cryptography Engineering, via une attaque « homme du milieu » le pirate se place donc entre le serveur et un navigateur (via un réseau Wi-Fi par exemple) afin de court-circuiter les négociations. Alors que le navigateur demande à utiliser un système de chiffrement RSA fort, le pirate modifie la demande en « export RSA » (faible). Le serveur répond avec une clé RSA de 512 bits, qui est ensuite acceptée par le navigateur « à cause d'un bug », même si ce n'était pas sa demande initiale. La connexion est donc chiffrée via RSA en 512 bits seulement. Pour rappel, l'ANSSI recommande une clé d'au moins 2048 bits pour un chiffrement asymétrique (comme le RSA) et même 4096 bits à partir de 2030.

Il suffit alors de factoriser cette clé de 512 bits (voir cette actualité pour plus de détail) pour décrypter la connexion. Toujours selon Cryptography Engineering, en utilisant le cluster EC2 d'Amazon et un algorithme spécialement conçu pour, il serait possible de factoriser un tel nombre en 7h30 environ, pour un coût d'un peu plus d'une centaine de dollars. Une fois les clés privées trouvées, le pirate peut alors lire et modifier toutes les données comme s'il était dans la Matrice : il a un accès total aux données échangées et peut modifier à loisir l'apparence du site alors que la connexion est toujours sécurisée pour le navigateur. 

Le coût annoncé n'est pas négligeable (100 dollars environ par clé), mais les choses se gâtent puisque, par défaut, Apache générerait une clé de chiffrement « export RSA » et le conserverait tout le temps où le serveur est démarré, sans la renouveler. Conséquence directe de cette situation, une fois cette clé factorisée par un pirate, attaquer d'autres utilisateurs sur un même serveur serait un jeu d'enfant.

Qui est concerné ? 

Selon les chercheurs à l'origine de cette découverte, Chrome sur Android et Safari (sur iOS et OS X) seraient vulnérables à FREAK. Un test a été mis en ligne afin de vous permettre de vérifier ce qu'il en est. D'après nos constations, Chrome, Firefox et Internet Explorer dans leur dernière version pour Windows ne sont pas concernés. Il en est de même pour Firefox sur Android et Chrome sur iOS.

FREAK iOSFREAK iOS
Safari sur iOS et Chrome sur iOS

Du côté des sites internet, la situation serait plus grave puisque, si l'on en croit Freakattack, 12,2 % des sites les plus visités selon Alexa seraient touchés. On y trouve par exemple ceux de la NSA, de la Maison-Blanche, du FBI ainsi que la page de Facebook Connect, bien que cette dernière ait déjà été mise à jour selon Cryptography Engineering. De son côté, Akamai a mis en ligne un billet de blog afin d'indiquer que son réseau avait d'ores et déjà été mis à jour, mais qu'il restait encore des risques sur ceux de certains de ses clients. On y retrouve également une commande permettant de tester son serveur.

Interrogé sur le sujet par nos confrères de Dark Reading, Ivan Ristic, directeur de l'ingénierie chez Qualys, indique que « l'attaque semble assez facile, conceptuellement [...] Dans la pratique, je ne pense pas que ce soit un très gros problème de sécurité » ajoute-t-il. Il faut en effet réunir plusieurs éléments en même temps : serveurs et clients vulnérables, casser la clé, et le tout avec une attaque « homme du milieu » qui n'est pas toujours facile à mettre en place.

71

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

FREAK : une attaque basée sur un reliquat des années 90 avec « export RSA »...

... et hop la connexion est chiffrée avec une clé de 512 bits seulement

Qui est concerné ? 

Commentaires (71)


La tablette Android Lenovo que je viens de prendre est vulnérable..


Je trouve ca un peu étrange qu’on dise “homme du milieu” et pas “homme au milieu” pour “man in the middle”



Généralement quand on parle “du milieu” c’est pour supposer un attachement à un groupe, environnement etc. alors que “au milieu” est bien la position.









DDReaper a écrit :



La tablette Android Lenovo que je viens de prendre est vulnérable..





Au moins tu as la preuve que c’est une Lenovo originale du coup <img data-src=" />



Oui, comme précisé dans l’actu Chrome sur Android est vulnérable&nbsp;<img data-src=" />


C’est le navigateur qui est vulnérable, essaye Firefox ;)


Hum… Mon Firefox 36 est annoncé comme vulnérable.








CryoGen a écrit :



Je trouve ca un peu étrange qu’on dise “homme du milieu” et pas “homme au milieu” pour “man in the middle”





C’est parce que c’est surement un hobbit.



Super nouvelle, apparemment, tous mes navigateurs sont vulnérables…

Chrome me dit qu’il y a une mise à jour, on verra après… Mise à jour faite, toujours vulnérable…

Firefox, bah lui, non, pas de mise à jour, mais vulnérable.

IE est vulnérable, mais je m’attends pas à ce que ce soit corrigé avant mardi prochain…

&nbsp;








BlackKrystal a écrit :



Hum… Mon Firefox 36 est annoncé comme vulnérable.





FF 38 est safe sur Android et sur Windows.



Oui mais dans ce cas Gandalf ne devrait pas laisser passer ce genre d’attaque <img data-src=" />








BlackKrystal a écrit :



Hum… Mon Firefox 36 est annoncé comme vulnérable.









ArchangeBlandin a écrit :



Super nouvelle, apparemment, tous mes navigateurs sont vulnérables…

Chrome me dit qu’il y a une mise à jour, on verra après… Mise à jour faite, toujours vulnérable…

Firefox, bah lui, non, pas de mise à jour, mais vulnérable.

IE est vulnérable, mais je m’attends pas à ce que ce soit corrigé avant mardi prochain…









sous Windows mon Firefox 36 est annoncé ok <img data-src=" />





Good News! Your browser appears to be safe from the FREAK Attack!



je confirme








CryoGen a écrit :



sous Windows mon Firefox 36 est annoncé ok <img data-src=" />





Idem pour FF36 sur une Gentoo.



J’ai bien un firefox 36 aussi, mais ça l’indique vulnérable…





  • &nbsp;Warning! Your client is vulnerable to CVE-2015-0204. Even though your client doesn’t offer any RSA EXPORT suites, it can still be tricked into using one of them. We encourage you to upgrade your client.&nbsp;





    Chrome&nbsp;Version 41.0.2272.76 m est indiqué vulnérable aussi…



  • &nbsp;Warning! Your client is vulnerable to CVE-2015-0204. Even though your client doesn’t offer any RSA EXPORT suites, it can still be tricked into using one of them. We encourage you to upgrade your client.




Il est pourtant annoncé que la dernière version de Firefox est sûre… S’entends dernière version stable, et non bêta/Aurora.

Chromium, dans sa dernière build (319006) a le même problème.



A Contrario, Opera, dans sa dernière version stable (27.0.1689.76) est safe.



Edit : IE 11 est vulnérable aussi chez moi.



Hypothèse : l’antivirus qui analyse à la volée le HTTPS ?


A priori d’après le test IE 11 et ff36 que j’ai dessus sont OK.


firefox 37 - canal beta - windows 7 x64



--&gt; vulnerable 







Khalev a écrit :



FF 38 est safe sur Android et sur Windows.






 c'est bien la version du canal aurora?      

parce que bon...






&nbsp;Chrome --&gt; vulnerable ne l'etat. plantage en boucle sur la demande de mise jour      

je tente une reinstall...





&nbsp;edit 2: apres re dl et tout version cana beta : Chrome vulnerable…



&nbsp;   



&nbsp;IE11 11.0.9600.17633 - 11.0.16 (KB3021952)



vulnerable&nbsp;edit: bon comme d'hab j'entrave rien aux balises trucs machin des commspas moyen de coller les infos du test&nbsp;








TaigaIV a écrit :



Idem pour FF36 sur une Gentoo.





Ma Gentoo est en train de le compiler <img data-src=" />



Selon le test : sur mon Mac Yosemite :

Opéra : Vulnérable

Firefox : non vulnérable

Chrome : non vulnérable

Safari : vulnérable


Possible car ni mon Firefox 36, ni mon IE11 (sous Win8.1) ne sont vulnérables.


Du coup, si certains pouvaient m’expliquer pourquoi certains ont un resultat OK et d’autre non pour un meme navigateur (meme version)

OS?








CryoGen a écrit :



Ma Gentoo est en train de le compiler <img data-src=" />





Testé sur une 36.0 (binaire et compilée), la 36.0-r1 est en cours de compil. <img data-src=" />





un pirate peut décrypter les échanges de données&nbsp;sécurisées entre un&nbsp;serveur et navigateur web.



Tu voulais dire “déchiffrer” non ? <img data-src=" />


De même que FF 36 sous Fedora 21








AC_2009 a écrit :



Du coup, si certains pouvaient m’expliquer pourquoi certains ont un resultat OK et d’autre non pour un meme navigateur (meme version)

OS?







Antivirus / Firewall vulnérable installé sur le pc (ironique du coup) qui fait la connexion https à la place du navigateur pour pouvoir inspecter les flux.

Pare-feu / proxy de l’entreprise

Spyware

Module



Bref, des raisons il y en a :)



Précisions :Selon le test : sur mon Mac Yosemite :&nbsp;Opéra 27.0 : Vulnérable&nbsp;Firefox 36.0 : non vulnérable&nbsp;Chrome 41.0 : non vulnérable&nbsp;Safari 8.0.3 : vulnérable&nbsp;


Test fait avec Firefox 36 et Avast.





  • Vulnérable avec Avast activé

  • Ok avec Avast désactivé



    Ça semble confirmé ton hypothèse.


Y’a une MAJ Avast, j’installe, redémarre et teste.


Non, c’est la bonne utilisation qui est faite ici.




  • Chiffrer : opération légitime de modification pour rendre le message illisible

  • Déchiffrer : opération légitime de modification pour rendre le message lisible

  • Décrypter : opération illégitime de modification pour rendre le message lisible




peut etre que l’OS compte aussi ?

Par exemple FF36 sous Win 7 est vulnérable (c’est mon cas) alors que sous Win8, il ne l’est pas ?


Sous Windows 8.1 :

Chrome 40.0.2214.115 m : Non vulnérable

FireFox 36.0 : Non vulnérable

IE 11.0.9600.17631 : Non vulnérable



C’est étrange que pour ces mêmes versions certaines personnes n’ont pas le même résultat. Le test de freakattack.com est-il vraiment fiable ? :s



Edit: Ah oui effectivement, avec une suite de sécurité installée ça peut jouer… Je n’ai que le parefeu Windows et Windows Defender sur ma machine, pas de suite tierce.








Ricard a écrit :



Tu voulais dire “déchiffrer” non ? <img data-src=" />







non, Il a raison, c’est bien décrypter dans ce cas.



FF 36 non vulnérable chez moi :)



Sinon, le bouton “Signaler” étant introuvable à son emplacement habituel , voila une petit coquille&nbsp; :

“nos constations”



Pour casser une clef 512 il suffit de quelques ordinateurs actuels du calcul distribué&nbsp; , des outils comme GGNFS / MSIEVE et d’un peu de temps (semaines).








mon serveur a écrit :



3072784060:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:





mon serveur est plus sécurisé que celui de la NSA! <img data-src=" />

<img data-src=" />



Quand tu scroll, le bouton apparaît juste à coté de l’icone NXI, en haut à gauche.



Mais faut scroller un peu.


Firefox 38a2 ne l’est pas


c’est encore un petard mouillé ce truc



un serveur web bien configuré n’autorise plus cet algorithme depuis bien longtemps



donc, seul les serveur web mal configuré et/ou pas du tout à jour seront concerné



bref, un gros problème de compétence des admin reseau dans ce cas








geekounet85 a écrit :



mon serveur est plus sécurisé que celui de la NSA! <img data-src=" />

<img data-src=" />







y a une manip pour locker le truc sur apache ?



Parce que bon pour moi c’est plus une faille serveur que navigateur, non ?









gaetan.cambier a écrit :



c’est encore un petard mouillé ce truc



un serveur web bien configuré n’autorise plus cet algorithme depuis bien longtemps



donc, seul les serveur web mal configuré et/ou pas du tout à jour seront concerné



bref, un gros problème de compétence des admin reseau dans ce cas







Comment on fait pour check ses serveurs ?



La preuve que non, tu actives Avast et paf!, tu as la faille !



Donc pour les navigateurs peut-être, mais il existent des milliers de logiciels qui utilisent des connexions SSL qui ont potentiellement le problème !


comme le dis un des lien de l’article :&nbsp;openssl s_client -connect www.akamai.com:443 -cipher&nbsp;EXPORT

ou faire un check sur&nbsphttps://www.ssllabs.com/

et voir si le export rsa est dans la liste des ciphers&nbsp;


si le serveur n’accepte pas l’export rsa, aucun problème –&gt; les admin reseau doivent aurait du le desactiver depuis longtemps


Perso sur linux Mint :

-Chrome&nbsp;40.0.2214.115 non vulnérable

-Firefox 36 non vulnérable


Apparemment la dernière màj d’Avast résout le soucis.

Certains logiciel de sécurité ont des retards dans leur mise-à-jour on dirait <img data-src=" />








gaetan.cambier a écrit :



si le serveur n’accepte pas l’export rsa, aucun problème –&gt; les admin reseau doivent aurait du le desactiver depuis longtemps





Par souci de tranquillité, j’ai vérifié en openssl mon apache sur dedibox (projet-perso-que-j’ai-pas-trop-le-temps-de-suivre-etc <img data-src=" />) et il est safe… Par défaut, car je ne me rappelle pas avoir volontairement traité ce point en particulier lors de la mise en service.



comme je suis sur nginx pour le SSL termination et que j’ai limité pas mal les CIPHERS, je pense que ça joue pas mal sur la sécurité du bouzin à la base. <img data-src=" />

pour apache, je sais pas.



edit : vérifie surtout ta version d’openssl, c’est ça qui doit jouer!








Faktis a écrit :



Test fait avec Firefox 36 et Avast.

Vulnérable avec Avast activéOk avec Avast désactivéÇa semble confirmé ton hypothèse.





PAREIL

&nbsp; FF IE et chrome OK qd avast desactivé

huhu la loose



Le site de la NSA est vulnérable ? j’attaque de suite.








mononokehime a écrit :



Le site de la NSA est vulnérable ? j’attaque de suite.



Il y a un formulaire sur le site où tu peux choisir à l’avance la taille de ta combi.

Bon, pour les couleurs c’est spartiate, y’a que l’orange.









BlackKrystal a écrit :



A Contrario, Opera, dans sa dernière version stable (27.0.1689.76) est safe.



Idem avec l’historique Opera 12.17 (Presto)







gaetan.cambier a écrit :



comme le dis un des lien de l’article : openssl s_client -connect www.akamai.com:443 -cipher EXPORT

ou faire un check sur&#160https://www.ssllabs.com/

et voir si le export rsa est dans la liste des ciphers



Bizarrement, openssl ne me retourne pas d’erreur sur mon serveur, alors qu’il n’y a bien plus — oublié de MàJ la SSLCipherSuite la dernière fois, oups ! — la moindre trace d’EXPORT avec le test de SSL Labs. <img data-src=" />







gaetan.cambier a écrit :



si le serveur n’accepte pas l’export rsa, aucun problème



Et si le client refuse un format qu’il n’accepte pas aussi… <img data-src=" /> Perso, je préfère plutôt savoir qu’il n’y a pas de problème côté client que côté serveur, puisqu’en tant qu’utilisateur, tu as rarement le contrôle sur le serveur distant.



Non, c’est une attaque man in the middle - c’est le client qu’il faut vérifier.


&nbsp;







linkin623 a écrit :



Quand tu scroll, le bouton apparaît juste à coté de l’icone NXI, en haut à gauche.



Mais faut scroller un peu.





Oups, effectivement , merci&nbsp; <img data-src=" />

Fatigué moi<img data-src=" />



J’ai failli le dire, sauf qu’en y réfléchissant, ce n’est pas juste une attaque de type MITM qu’il faudrait mettre en place pour y parvenir, mais posséder la clé de chiffrement d’un certificat racine accepté par le client, puisque si le serveur n’émet pas ce genre de certificat, il faudra en générer un correctement/suffisamment signé pour que le client n’y voie que du feu.



Le premier qui pense à SuperFish, il peut sortir… Bon bah je suis dehors si vous me cherchez… <img data-src=" />









cedricpc a écrit :



Bizarrement, openssl ne me retourne pas d’erreur sur mon serveur, alors qu’il n’y a bien plus — oublié de MàJ la SSLCipherSuite la dernière fois, oups ! — la moindre trace d’EXPORT avec le test de SSL Labs. <img data-src=" />



Je n’ai rien dit, problème de vhost. <img data-src=" />



si il y a aucun algorithme en commun –&gt; connection refusée



laisser des vieux algorithme sous pretexte d’un très vieux client en aurait besoin, c’est de la pure connerie. meme ie6/windowsxp a de meilleure algorithme, alors faut le laisser pour qui ?



meme mozilla, dans son guide en version “Old_backward_compatibility” l’a supprimé depuis longtemps

https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility



c’est comme çà qu’on arrive à des problème de sécurité sans raison


Ah mais je ne dis pas non plus qu’il faut le laisser côté serveur pour autant. Je dis juste que du point de vue utilisateur, il vaut mieux utiliser un client qui n’accepte pas ce genre de certificat plutôt que de juste faire confiance à la bonne configuration du serveur, sachant qu’il en restera toujours une partie qui n’est pas correctement configurée.



Donc à mon sens, la mise à jour des clients vulnérables est prioritaire, bien que la désactivation côté serveur soit elle aussi indispensable pour tout bon SysAdmin qui se respecte.


Chez moi sous FF35 et Avast activé c’est OK… Très étrange effectivement.


Une curiosité ? ? ? :



FF 36 nickel sous MacOs Mountain Lion mais

FF 36 vulnérable sous windows 7-32bits …

Pas encore essayé sous Nuxe.

&nbsp;

Je ne comprends pas comment est réalisé le test. Quelqu’un a une idée ?


il verifie juste la liste des ciphers que le navigateur propose

tu peux voir la liste simplement en testant ton navigateur ici :

https://www.ssllabs.com/ssltest/viewMyClient.html


T’avais peut être installé sans le savoir la dernière MAJ Avast en arrière plan (maintenant, il ne demande plus de redémarrage, il attends).



Et effectivement, avec la nouvelle MAJ, c’est bon (enfin, sous FF36, pas encore testé les autres).


ben c’est sur, faut aussi que les navigateur se décide à supprimer de leur liste les different cypher completement obsolète



le problème, c’est qu’ils le laissent pour une raison de compatibilité …

enfin, pour savoir se connecter au site qui ne propose rien de mieux, mais à un moment, faut dire stop&nbsp;quitte a supprimer l’acces a quelques site dont la securité est pourrie&nbsp;


Le site lance deux requêtes vers deux serveurs distincts, l’un pour obtenir la liste des modes de chiffrement acceptés par le navigateur et le second spécialement adapté pour forcer l’utilisation du mode EXPORT. Si dans le premier cas, il un mode blacklisté est autorisé, le test échoue. Et si dans le second cas, la requête aboutie, ça veut dire que le navigateur est vulnérable à la faille FREAK, et donc le test échoue aussi.



Le plus probable dans ton cas, c’est que tu as un antivirus ou autre qui intercepte les données en HTTPS qui est lui-même vulnérable — voir précédents commentaires.



Édit : Oups, partiellement grillé… <img data-src=" />








BlackKrystal a écrit :



Hum… Mon Firefox 36 est annoncé comme vulnérable.



Firefox 39 (Nightly) ne l’est pas (du moins sous Linux)





Good News! Your browser appears to be safe from the FREAK Attack!



<img data-src=" />



Ok, merci pour ces informations …

<img data-src=" />


Entièrement d’accord. <img data-src=" /> J’en ai profité pour faire un bon coup de nettoyage dans les options de mon navigateur d’ailleurs. <img data-src=" />



Le mieux, ça serait peut-être qu’ils bloquent d’office toutes les vieilles méthodes de chiffrement, tout en offrant la possibilité de pouvoir les réactiver temporairement pour un serveur non compatible après avoir affiché un gros message d’erreur, comme la plupart le font déjà pour les certificats non signés par une autorité de confiance… Sauf qu’au lieu de parler de confiance, il faudrait que le bouton indique clairement « J’ai bien conscience que cette connexion pourra être déchiffrée par un tiers malveillant », ça devrait suffisamment faire peur. <img data-src=" />









Vin Diesel a écrit :



Ok, merci pour ces informations …

<img data-src=" />



Mais je t’en prie. <img data-src=" />









gaetan.cambier a écrit :



, mais à un moment, faut dire stop&nbsp;quitte a supprimer l’acces a quelques site dont la securité est pourrie&nbsp;&nbsp;



On est d’accord.

&nbsp;

Cependant, l’utilisateur aura vite fait de changer de crèmerie… Ce qui n’arrange pas les maisons éditrices de nos précieux butineurs.









Vin Diesel a écrit :



Une curiosité ? ? ? :



FF 36 nickel sous MacOs Mountain Lion mais

FF 36 vulnérable sous windows 7-32bits …

Pas encore essayé sous Nuxe.

&nbsp;

Je ne comprends pas comment est réalisé le test. Quelqu’un a une idée ?





C’est simple.

Le FF est vulnérable des deux cotés - mais - la librairie sécu de MacOS ne gère pas le chiffrement sur 512.



Je ne peux pas m’en rendre compte. La Yoga que j’ai acheté en novembre à déjà passé &nbsp;3 mois en réparation. Je l’attends toujours….<img data-src=" />


Pluzun



Win7_FF36.0 <img data-src=" />


Non absolument aucun rapport…



Firefox n’est pas vulnérable, ces faibles modes de chiffrement ne sont plus activés par défaut depuis la version 2 et le retrait total doit remonter à quelques années maintenant. Du côté d’Opera, ils ont même carrément été supprimés depuis la version 9.50, donc la faiblesse est bien connue depuis très longtemps.



En plus, Firefox n’utilise pas OpenSSL donc il n’est même pas concerné par la CVE 2015-0204.



Et le comble dans tout ça, c’est que Safari est justement vulnérable, comme dit dans l’article. Alors je ne sais pas s’il utilise son propre mécanisme pour SSL/TLS, mais s’il y a un navigateur qui a de grandes chances d’utiliser la bibliothèque native du système, c’est bien lui ! Et en général, ces bibliothèques ne font pas l’impasse sur certains modes, c’est le logiciel qui l’exploite qui va autoriser tels modes plutôt que d’autres.



Comme cela a déjà été dit dans les précédents commentaires, la véritable raison est que quelque chose d’autre intercepte les flux HTTPS et que ce quelque chose est justement vulnérable, typiquement un antivirus. Et comme ce n’est pas trop le genre de protection que l’on retrouve sous Linux ou Mac OS X, bah forcément on ne retrouve ce problème quasiment que sur Windows.


La version 36.0.1 de Firefox corrige le pb sous Windows 7


Apparament le problème est un poil plus compliqué, et le test fourni ici n’est pas complet. MS considère que cette faille touche d’une manière ou d’une autre à peu près tout le monde :&nbsp;https://technet.microsoft.com/en-us/library/security/3046015?f=255&MSPPError=-2147217396



Y&nbsp;a du patch qui va tomber à priori, OpenSSL ou pas…


J’avais encore la 35.0.1 il n’y a pas longtemps et cette version n’était pas plus vulnérable. ;) Voir mon précédent commentaire où j’explique que la suppression de l’EXPORT ne date pas d’hier pour certains navigateurs.









Bejarid a écrit :



Apparament le problème est un poil plus compliqué, et le test fourni ici n’est pas complet. MS considère que cette faille touche d’une manière ou d’une autre à peu près tout le monde : https://technet.microsoft.com/en-us/library/security/3046015?f=255&MSPPError=-2147217396



Y a du patch qui va tomber à priori, OpenSSL ou pas…



Il n’y a rien de compliqué du tout, c’est juste que Schannel, qui est la bibliothèque SSL/TLS de Windows, a une vulnérabilité similaire à OpenSSL. Donc les tests actuels sont déjà parfaitement en mesure de détecter le problème puisque la finalité est la même, à savoir que la connexion est acceptée alors qu’elle n’aurait jamais dû l’être.



Et à part Internet Explorer, aucun des principaux concurrents n’utilise cette bibliothèque. Par contre, comme pour la faille d’OpenSSL, tous les programmes reposant sur Schannel sont vulnérables. Donc tu peux être sûr que tous les produits Microsoft pouvant se connecter en SSL/TLS le sont, et ce ne sont forcément pas les seuls.