La faille POODLE de SSLv3 permet de décrypter les données sur une connexion

La faille POODLE de SSLv3 permet de décrypter les données sur une connexion

Tous les navigateurs vont être mis à jour

54

La faille POODLE de SSLv3 permet de décrypter les données sur une connexion

Une importante faille de sécurité a été découverte dans la version du protocole SSL par une équipe de chercheurs travaillant chez Google. Elle pourrait permettre à des pirates de s’insérer entre un serveur et un client pour récupérer des informations chiffrées. La seule protection efficace semble être la désactivation totale du protocole.

Une faille qui permet de décrypter les données

Bodo Möller, Thai Duong et Krzysztof Kotowicz, trois chercheurs en sécurité travaillant chez Google, ont publié les détails d’une faille de sécurité dans le protocole SSLv3. Nommée POODLE, pour « Padding Oracle On Downgraded Legacy Encryption », elle permet de récupérer à l’insu de l’internaute des données chiffrées envoyées par sa machine. Cette récupération s’effectue en plusieurs étapes, dont la première consiste en une « downgrade dance » dont le but est d’affirmer au serveur que le client ne supporte pas mieux que le SSLv3.

 

Car SSLv3 a beau être la dernière révision de ce protocole, il n’en est pas moins ancien et a été supplanté par TLS (Transport Security Layer), dont la version 1.0 a été publiée en 1999 par l’IETF. La « downgrade dance » doit donc faire croire au serveur que le client ne supporte pas TLS et qu’il doit basculer sur SSLv3 pour garder une connexion sécurisée. SSL étant moins protégé que TLS (qui n’est d’ailleurs pas concerné par cette faille), l’exploitation de la brèche devient possible.

 

L’attaque se fait sur un mode « man-in-the-middle », via par exemple un faux point d’accès Wi-Fi ou encore un fournisseur d’accès dont la sécurité aurait été compromise. Le pirate peut compter sur le fait que SSLv3, contrairement à TLS, fait l’impasse sur la validation de certaines informations qui accompagnent les données. Petit à petit, le pirate pourra décrypter un octet de chaque trame jusqu’à pouvoir reconstituer les cookies de connexions HTTP. À terme, il finira par obtenir en clair l'ensemble des données circulant sur la connexion car le processus de chiffrement aura été cassé.

Navigateurs : on peut agir en partie dès maintenant 

Si la faille est importante, les leviers d’action ne manquent pas. Côté serveurs par exemple, les administrateurs peuvent complètement désactiver SSLv3 et former l’obligation de TLS, idéalement dans sa mouture 1.2, soit la plus récente. Mais évidemment, les choses ne sont pas aussi simples. Il y a en effet un facteur qui risque de faire grincer des dents à une partie des utilisateurs : de nombreux anciens logiciels et système ne sont pas compatibles avec TLS. Parmi eux, Internet Explorer 6  dans Windows XP, qui ne supporte que SSLv3. Si les entreprises peuvent être informées du problème, il sera beaucoup plus délicat de faire basculer les particuliers. À moins évidemment que chaque entreprise mette en place sur son site web un avertissement invitant les utilisateurs à se tourner vers un autre navigateur.

 

Et encore, la situation des navigateurs est pour le moment mitigée. Un site web permet de tester leur vulnérabilité et, actuellement, seul Firefox 33 (qui vient tout juste de sortir) semble immunisé. Un autre consacré à la faille de sécurité dresse le bilan des actions à mener sur les serveurs et navigateurs, par exemple dans le cas d’Apache.

 

Mais pour les autres, notamment Chrome, la solution est peu souvent idéale, le navigateur de Google ne pouvant être épargné qu’à travers un commutateur ajouté dans son raccourci sur le bureau. En d’autres termes, si Chrome est ouvert via un lien dans un autre logiciel, le raccourci ne sera pas pris en compte. Dans Internet Explorer, la solution est beaucoup plus simple : il suffit de se rendre dans les options Internet, puis dans l’onglet Avancé et y désactiver « Utiliser SSL 3.0 ». Quant à Firefox, Mozilla a déjà réagi sur le sujet en annonçant que SSLv3 serait tout bonnement désactivé par défaut dans la future 34 du navigateur, prévue pour le 25 novembre (même si, comme déjà évoqué, la toute récente version 33 n'est pas vulnérable).

 

Le billet de Mozilla précise d’ailleurs que selon des études menées par l’éditeur et l’université du Michigan montrent qu’au sein du million de domaines les plus visités (selon Alexa), seuls 0,42 % d’entre eux s’appuient toujours sur SSLv3. Le fait de se débarrasser définitivement de ce protocole ne devrait donc pas avoir d’influence majeure. Cependant, pour les internautes concernés, certaines surprises sont à prévoir, mais puisque tous les navigateurs vont être mis à jour, il ne sera pas si complexe d’y remédier, même sur Windows XP.

 

Enfin, sachez que CloudFlare et Tor ont réagi à cette faille. Le premier a annoncé immédiatement la désactivation complète de SSLv3, tandis que le second a publié une page explicative montrant comment changer la configuration du Tor Browser pour forcer l'utilisation de TLS.

Commentaires (54)


décrypter => déchiffrer :)

Sinon merci pour ces infos !


Il me semble que le paramètre Firefox (ceux qui veulent garder une version < 33 ) pour refuser une connexion SSLv3 est security.tls.version.min qui doit être à 1.



 








bsod a écrit :



décrypter => déchiffrer :)

Sinon merci pour ces infos !





C’est bien décrypter ici, le gars au milieu n’a pas les clés de chiffrement :)









bsod a écrit :



décrypter => déchiffrer :)

Sinon merci pour ces infos !





C’est bien utilisé là. Le pirate casse le chiffrement sans en avoir la clef, donc il décrypte…





tous les navigateurs vont être mis à jour





Même IE 9 ? <img data-src=" />








bsod a écrit :



décrypter =&gt; déchiffrer :)

Sinon merci pour ces infos !





Déchiffrer = lire un message chiffré de façon légitime, quand tu disposes des clés.



Décrypter = lire un message chiffré de façon illégitime/illégale, en cassant le chiffrement.



Vincent a donc raison sur ce coup-là&nbsp;<img data-src=" />



Edit : bon multi-grilled mais au moins on est tous d’accord&nbsp;<img data-src=" />



Ok ok merci à tous je l’avais pas compris comme ça :)


Sinon Firefox 33 est sorti depuis 2 jours, paye ta réactivité <img data-src=" />


Dans Internet Explorer, la solution est beaucoup plus simple : il suffit de se rendre dans les options Internet, puis dans l’onglet Avancé et y désactiver « Utiliser SSL 3.0 »



Avec Opera 12.x, la désactivation de SSLv3 pourra aussi se faire simplement via les Préférences &gt; Avancées &gt; Sécurité &gt;&nbsp;Protocole de sécurité &gt; Décocher « Activer SSL 3 »


L’autre solution étant d’utiliser TLS_FALLBACK_SCSV pour ne pas passer sur SSLv3 alors que le client et le serveur savent faire ‘mieux’.

TLS_FALLBACK_SCSV








Goreman a écrit :



Sinon Firefox 33 est sorti depuis 2 jours, paye ta réactivité <img data-src=" />





Oui c’est sur que c’était plus vital que de parler de la faille dont il est question ici. Concernant FF33, on ne traite pas l’arrivée des nouvelles versions sur le FTP. Et je trouve toujours assez désagréable qu’on vienne nous reprocher de ne pas faire la course au traitement rapide de telle ou telle info. On est une rédaction, pas une équipe pendant le Tour de France <img data-src=" />



Je suis encore à la version 31.1.0 de Firefox, je suis donc vulnérable…yoopee ! <img data-src=" /> <img data-src=" />








Winderly a écrit :



Je suis encore à la version 31.1.0 de Firefox, je suis donc vulnérable…yoopee ! <img data-src=" /> <img data-src=" />





Le trick de @ href="http://www.nextinpact.com/inpactien/205029" target="_blank">unCaillou marche très bien.









ra-mon a écrit :



Avec Opera 12.x, la désactivation de SSLv3 pourra aussi se faire simplement via les Préférences &gt; Avancées &gt; Sécurité &gt;&nbsp;Protocole de sécurité &gt; Décocher « Activer SSL 3 »





Et avec 24.x ? <img data-src=" />



Hop, configuration apache de mes serveurs modifiée en conséquence. :)








bsod a écrit :



décrypter =&gt; déchiffrer :)

Sinon merci pour ces infos !





bsod =&gt; ebdlm :)&nbsp;



C’est la saison des failles en ce moment :(








john san a écrit :



C’est la saison des failles en ce moment :(





Adresse Web :

http://www.youtube.com/watch?v=jpFs862EqrU



<img data-src=" />



tiens c’est bizarre, j’ai lu d’autre chiffre pour l’utilisation de SSLv3 :

SSLv31,186 sites

(0.12% of Alexa, 0.02% of HTTPS Alexa)

&nbsp;et dans le tas… ya tout citybank qui est en sslv3


Les sysadmin sont vraiment gâtés ces temps-ci <img data-src=" />

Pour régler le problème sur Apache : SSLProtocol All -SSLv2 -SSLv3



https://scottlinux.com/2013/06/18/disable-sslv2-and-sslv3-in-apache/&nbsp; (article datant de 2008, ce mec a eu du nez)



Et pour les autres serveurs (Debian/Ubuntu) :

http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566

Attention, comme indiqué dans l’article, ça rend IE6 inopérant.


Je viens d’essayer le test avec Firefox 32.0.3 : c’est marqué qu’il n’est pas vulnérable à cette faille.








bsod a écrit :



décrypter =&gt; déchiffrer :)

Sinon merci pour ces infos !





C’est chiffrer qu’il faut utiliser à la place de crypter.&nbsp;

Ici c’est parfaitement juste.









raymondcal a écrit :



Je viens d’essayer le test avec Firefox 32.0.3 : c’est marqué qu’il n’est pas vulnérable à cette faille.






Idem sur la même version que toi la je fais la maj du coup ^^    



IE 11.0.9600.17280

Chrome 38.0.2125.104 m (64-bit)

Sont vulnerable









versgui a écrit :



Les sysadmin sont vraiment gâtés ces temps-ci <img data-src=" />



Pour régler le problème sur Apache : SSLProtocol All -SSLv2 -SSLv3







surement un complot des sysadmin chinois du FBI









versgui a écrit :



Les sysadmin sont vraiment gâtés ces temps-ci <img data-src=" />

Pour régler le problème sur Apache : SSLProtocol All -SSLv2 -SSLv3







En plus précis (Apache 2.2.x):





SSLEngine On



SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1   

SSLCompression off

SSLHonorCipherOrder on

SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM

Header set Strict-Transport-Security "max-age=15678000"

SSLOptions +ExportCertData +StrictRequire







Config honteusement piquée à Benjamin Sonntag sur une conf sur SSL/TLS (avec ajustement sur HSTS)



Ça a l’avantage de n’être pas compatible avec IE6 et 7 (<img data-src=" />), d’avoir une bonne gestion de la Forward Secrecy (en face de navigateur moderne).



Désavantage -&gt; TLSv1 est activé, mais pas RC4, ce qui peut poser des problèmes avec BEAST (mais les navigateurs ayant eux été corrigée, le problème est minime)









David_L a écrit :



On est une rédaction, pas une équipe pendant le Tour de France <img data-src=" />





Et c’est pour ça qu’on vous aime <img data-src=" />









Reznor26 a écrit :



Et avec 24.x ? <img data-src=" />








  Aucune idée.         

&nbsp;&nbsp; À noter qu'Opera 12.16 est indiquée non vulnérable sur https://www.poodletest.com/



http://xn–pp-oia.com/Hfv5 &nbsp;SSLv3 est activé par défaut mais une fois le test réalisé, il est automatiquement désactivé&nbsp;



Dans Internet Explorer, la solution est beaucoup plus simple&nbsp;: il suffit

de se rendre dans les options Internet, puis dans l’onglet Avancé et y

désactiver «&nbsp;Utiliser SSL 3.0&nbsp;».



IE11 64bit protect mod, je l’ai désactivé mais le site me montre toujours que j’ai la faille. <img data-src=" />








cide a écrit :



Idem sur la même version que toi la je fais la maj du coup ^^

IE 11.0.9600.17280

Chrome 38.0.2125.104 m (64-bit)

Sont vulnerable



sur IE 11.0.9600.17351 (en&nbsp;gros la version du patch tuesday d’hier) il est marqué non&nbsp;vulnérable chez moi









raymondcal a écrit :



Je viens d’essayer le test avec Firefox 32.0.3 : c’est marqué qu’il n’est pas vulnérable à cette faille.





Mais le test dis que lynx est vulnérable

<img data-src=" />



Une idée de comment on fait avec Safari ? (celui de Yosemite en ce qui me concerne ;))








levhieu a écrit :



Mais le test dis que lynx est vulnérable

<img data-src=" />









Naaaaaaaaaaan ! <img data-src=" />



Ce base pas sur les librairies openssl Lynx pour tout le bordel SSL/TLS ?



AU fait, juste comme ça, SSL et SSH, c’est lié ?&nbsp;

Car j’ai activé le SSHv2 sur mon Syno. C’est pas impacté par cette nouvelle faille ?








MilesTEG1 a écrit :



AU fait, juste comme ça, SSL et SSH, c’est lié ? 

Car j’ai activé le SSHv2 sur mon Syno. C’est pas impacté par cette nouvelle faille ?





SSH et SSL sont deux protocoles différents, donc aucun soucis à se faire.









MilesTEG1 a écrit :



AU fait, juste comme ça, SSL et SSH, c’est lié ?&nbsp;

Car j’ai activé le SSHv2 sur mon Syno. C’est pas impacté par cette nouvelle faille ?





Même question concernant le HTTPS utilisé par les routeurs/NAS; ils sont tous en TLS?









Qruby a écrit :



Même question concernant le HTTPS utilisé par les routeurs/NAS; ils sont tous en TLS?





J’allais poser la même question <img data-src=" />



Les Synology ont le SSLv3 d’activé par défaut. J’ai cherché à la désactiver à la main dans les fichiers de conf mais tout est éparpillé c’est le boxon donc on va voir si Syno compte sortir un update de DSM pour désactiver le SSL chez tout le monde.








Qruby a écrit :



Même question concernant le HTTPS utilisé par les routeurs/NAS; ils sont tous en TLS?





non ça dépend de la config des serveur.









XMalek a écrit :



Même IE 9 ? <img data-src=" />







Bah oui, il est toujours supporté jusqu’en 2017 sur Vista et 2016 sur Win7.



Au passage même IE6 est toujours supporté jusqu’en 2015 sur win2003 server.



D’ailleurs IE6 supporte TLS 1.0, mais il est désactivé par défaut. Donc pour ceux qui s’accrochent encore à IE6, il y a toujours moyen de couper SSL3 et d’activer TLS1.0









Glyphe a écrit :



Les Synology ont le SSLv3 d’activé par défaut. J’ai cherché à la désactiver à la main dans les fichiers de conf mais tout est éparpillé c’est le boxon donc on va voir si Syno compte sortir un update de DSM pour désactiver le SSL chez tout le monde.





Mouais j’attends encore le patch pour mon DS411+II. Je suis toujours en 5.0-4493 update5



Il m’a été confirmé, par l’ex-Monsieur Sécurité d’Opera Software, qu’Opera 12 était bien résistant à cette attaque à partir du moment où le serveur est bien patché contre la faille “TLS Renego” et qu’il supporte au moins TLS1.0 (80% des serveurs, d’après lui).

Le choix de ce mode de fonctionnement remonte à Opera 10.50 et est documenté sur

&nbsphttps://vivaldi.net/blogs/entry/standards-work-update&nbsp;

Il est aussi possible qu’Opera 12 conserve en cache la dernière version négociée du protocole et refuse tout repli vers une version moins fiable tant que le cache n’a pas expiré (30j).



Par contre, Opera 12 deviendrait vulnérable sur des serveurs non patché “TLS Renego” et qui ne supporteraient que SSL3, d’autant plus si l’utilisateur a volontairement désactivé le support de TLS dans les préférences d’Opera 12.


J’allais oublier : un site bien pratique qui permet de tester la qualité de la config TLS/SSL d’un site web (ils proposent de tester le navigateur aussi)


RAH.. again, snif ^^;



Donc si j’ai bien compris faut désactiver SSL sur Apache, même en v3.

C’est compatible avec tous les navigateurs modernes, donc tous sauf IE6 j’imagine.



OK…


<img data-src=" />En ce qui me concerne :



Firefox 33 : Vulnérable

Opera 12.17 : NON vulnérable

IE 11 : Vulnérable

Chromium : Vulnérable

MX Nitro : Vulnérable



Gagnant : Opera 12.17&nbsp;


Securité OpenSSL : il n’y a pas que Poodle qui mérite d’être patché

http://www.zdnet.fr/actualites/securite-openssl-il-n-y-a-pas-que-poodle-qui-meri…


Hier Firefox 33 non vulnérable

Aujourd’hui Firefox 33 vulnérable

Sous Linux Xubuntu 14.04








JCDentonMale a écrit :



&nbsp;Opera 12.17 : NON vulnérable&nbsp;

Chromium : Vulnérable

&nbsp;

Gagnant : Opera 12.17&nbsp;





&nbsp; D’après les explications données par Håvard Molland sur le blog “Sécu” d’Opera Software, les versions 25 d’Opera pour Windows et Android seraient aussi résistantes à cette attaque. La version pour Mac devra attendre une mise à jour d’iOS puisqu’elle utilise le SSL d’Apple.&nbsp;

http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks

Le poodletest.com ne serait peut-être pas aussi fiable que ça pour déterminer qui “gagne” à ce petit jeu, puisque si j’ai bien compris, Google aurait aussi repris l’idée de Molland pour sécuriser ses Chrome/Chromium.



&nbsp;Pour Opera 12, ils se contenteront de désactiver à distance (pendant une banale vérification de mise à jour automatique, je pense, ce qui expliquerait mieux ce que j’avais constaté hier dans mon message #27) le protocole SSLv3 de toutes les installations sur lesquelles ça n’aurait pas été fait manuellement, sans avoir besoin de &nbsp;distribuer une mise à jour binaire.



“seul Firefox 33 (qui vient tout juste de sortir) semble immunisé”

pas chez moi, j’ai bien la version 33 et le poodle test me dit vulnérable. (debian wheezy à jour)

&nbsp;








spike_boon a écrit :



“seul Firefox 33 (qui vient tout juste de sortir) semble immunisé”

pas chez moi, j’ai bien la version 33 et le poodle test me dit vulnérable. (debian wheezy à jour)

&nbsp;





Pareil …



Version 33, Vulnérable, Gnu Linux Mint Mate 17.









Winderly a écrit :



Je suis encore à la version 31.1.0 de Firefox, je suis donc vulnérable…yoopee ! <img data-src=" /> <img data-src=" />





cherche le greffon &nbsp; SSL Version Control 0.2 sous FF .. je sais plus ou j’avais trouvé ça … et ça corrige.









FRANCKYIV a écrit :



Pareil …



Version 33, Vulnérable, Gnu Linux Mint Mate 17.





j’ai désactivé sslv3 et je suis plus vulnérable :&nbsp; dans about:config mettre 1 pour security.tls.version.min









spike_boon a écrit :



j’ai désactivé sslv3 et je suis plus vulnérable :&nbsp; dans about:config mettre 1 pour security.tls.version.min







Je viens de tester, ça fonctionne nickel … marchi !!! <img data-src=" />



Vous pouvez utiliser ce site https://www.howsmyssl.com/ pour savoir qu’elles sont les versions de SSL et TLS permises dans votre navigateur. :)



Pour les version de Firefox inférieur à la 33, voici quelques petites modifications à faire dans “about:config” :





  • security.tls.version.max =&gt; 3 (pour permettre à Firefox de commencer à essayer de communiquer en TLS v1.3 au lieu de demander du v1.0)

  • security.tls.version.min =&gt; 1 (histoire d’avoir TLS 1.0 au moins et non SSLv3)




Source des infos ci-dessus.


Fermer