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)
#1
décrypter => déchiffrer :)
Sinon merci pour ces infos !
#2
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.
#3
#4
#5
tous les navigateurs vont être mis à jour
Même IE 9 ? " />
#6
#7
Ok ok merci à tous je l’avais pas compris comme ça :)
#8
Sinon Firefox 33 est sorti depuis 2 jours, paye ta réactivité " />
#9
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 > Avancées > Sécurité > Protocole de sécurité > Décocher « Activer SSL 3 »
#10
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
#11
#12
Je suis encore à la version 31.1.0 de Firefox, je suis donc vulnérable…yoopee ! " /> " />
#13
#14
#15
Hop, configuration apache de mes serveurs modifiée en conséquence. :)
#16
#17
C’est la saison des failles en ce moment :(
#18
#19
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)
et dans le tas… ya tout citybank qui est en sslv3
#20
Les sysadmin sont vraiment gâtés ces temps-ci " />
Pour régler le problème sur Apache : SSLProtocol All -SSLv2 -SSLv3
https://scottlinux.com/2013/06/18/disable-sslv2-and-sslv3-in-apache/ (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.
#21
Je viens d’essayer le test avec Firefox 32.0.3 : c’est marqué qu’il n’est pas vulnérable à cette faille.
#22
#23
#24
#25
#26
#27
#28
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 ».
IE11 64bit protect mod, je l’ai désactivé mais le site me montre toujours que j’ai la faille. " />
#29
#30
#31
Une idée de comment on fait avec Safari ? (celui de Yosemite en ce qui me concerne ;))
#32
#33
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 ?
#34
#35
#36
#37
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.
#38
#39
#40
#41
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
 https://vivaldi.net/blogs/entry/standards-work-update
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.
#42
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)
#43
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…
#44
" />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
#45
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…
#46
Hier Firefox 33 non vulnérable
Aujourd’hui Firefox 33 vulnérable
Sous Linux Xubuntu 14.04
#47
#48
“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)
#49
#50
#51
#52
#53
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” :
#54
Source des infos ci-dessus.