La faille Poodle exploitable avec TLS dans certains cas
The Neverending Story
Le 10 décembre 2014 à 13h30
3 min
Internet
Internet
La faille Poodle, exploitable avec le protocole SSLv3, peut également fonctionner avec TLS dans certains cas. Bien que moins grave, elle toucherait environ un serveur sur dix, mais elle peut être bloquée en procédant aux mesures qui s’imposent.
Poodle, de SSL à TLS
La faille Poodle a sonné le glas de SSLv3. Cet ancien protocole, utilisé pour les connexions sécurisées HTTPS, s’occupait de chiffrer les données. Il a été remplacé par une version nettement mieux armée, TLS, qui en est aujourd’hui à sa mouture 1.2. En réaction à Poodle, qui permettait de décrypter des données qui auraient dû normalement rester hors d’atteinte, la plupart des navigateurs ont désactivé, voire supprimé complètement SSLv3, en exigeant que le serveur soit compatible TLS.
Mais comme nous l’indiquions dans notre précédente actualité sur la sécurité d’Internet Explorer, la faille Poodle (Padding Oracle On Downgraded Legacy Encryption) peut en fait être aussi exploitée avec TLS quand certaines conditions sont réunies. Là encore, des pirates pourraient tout à fait mettre en place une attaque de type « man-in-the-middle », permettant d’intercepter des données et de les décrypter. La faute à certains produits qui ne vérifient pas assez la structure de chiffrement dans les paquets transmis.
En cas de vulnérabilité, l'attaque est plus simple à mettre en place
Un problème mis en avant par la société de sécurité Qualys. L’un de ses responsables, Ivan Ristic, explique ainsi : « L'impact de ce problème est similaire à celui de Poodle, avec une attaque légèrement plus simple à lancer : pas besoin de rétrograder les clients modernes vers SSLv3 d'abord, TLS 1.2 fera très bien l’affaire. Les cibles principales sont les navigateurs, puisque l'attaquant doit injecter un JavaScript malveillant pour lancer l'attaque. Une attaque réussie utilisera environ 256 demandes pour décrypter un cookie d’un seul caractère, ou seulement 4 096 demandes pour un cookie de 16 caractères. Ce qui rend largement l’attaque faisable ».
Qualys propose d’ailleurs un test pour entrer l’adresse d’un site et tester ainsi la vulnérabilité potentielle de l’implémentation faite de TLS.
Des correctifs à appliquer
Le problème a été noté initialement par Brian Smith, de chez Mozilla. Il avait remarqué que d’anciennes versions des Network Security Services (bibliothèque de chiffrement utilisée dans Firefox notamment) étaient concernées. Dans une discussion avec le chercheur en sécurité chez Google Adam Langley, il est vite apparu que ce dernier se doutait que le problème pouvait affecter d’autres produits. Grâce à un outil pour détecter la présence de la vulnérabilité, il s’est notamment rendu compte que des répartiteurs de charge provenant de F5 Networks et A10 Networks étaient concernés.
Langley indique sur son blog n’être « pas tout à fait certain d'avoir trouvé tous les fournisseurs affectés mais, maintenant que le problème est rendu public, tout autre produit affecté devrait être rapidement signalé ». De son côté, Qualys estime qu’environ 10 % des serveurs dans le monde sont concernés.
Qu’il s’agisse des équipements réseau ou des serveurs, des correctifs ont déjà été distribués dans plusieurs cas quand les produits sont vulnérables. Dans la plupart des cas cependant, l’implémentation de TLS a été réalisée correctement.
La faille Poodle exploitable avec TLS dans certains cas
-
Poodle, de SSL à TLS
-
En cas de vulnérabilité, l'attaque est plus simple à mettre en place
-
Des correctifs à appliquer
Commentaires (28)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/12/2014 à 14h43
En cas de vulnérabilité, l’attaque est plus simple à mettre en place
" />
Le 10/12/2014 à 14h57
En effet
Le 10/12/2014 à 15h12
Sinon tu peux lire aussi la phrase en entier " />
Le 10/12/2014 à 15h14
Le 10/12/2014 à 15h25
Eventually " />
Le 10/12/2014 à 15h32
Le 10/12/2014 à 15h32
C’est la phrase complète (titre du paragraphe) " />
Je taquine
Le 10/12/2014 à 15h38
" />" />" />
Le 10/12/2014 à 16h32
Donc d’après votre capture d’écran www.nextinpact.com votre configuration TLS est classé A. Bien, sauf qu’en réalité il y a une redirection https -> http. Il y a pas un loup là ?
Perso ça me donne pas envie de lire la suite de l’article !
Le 10/12/2014 à 16h52
Le “www” n’est pas prévu pour du https, donc effectivement redirection.
Le “compte” est en https.
Le 10/12/2014 à 17h53
Sur mon serveur j’avais désactivé SSLv3 mais laissé toutes les version pour TLS, est-ce utile de ne laisser que la 1.2 ?
J’ai fait le test et ça me sort 3 points auquel me demande comment remédier :
-Certificate has a weak signature and expires after 2016. Upgrade to SHA2 to avoid browser warnings.
-This server accepts the RC4 cipher, which is weak. Grade capped to B.
-The server does not support Forward Secrecy with the reference browsers.
Une idée ?
Le 10/12/2014 à 19h14
j’avais les mêmes
pour la signature de certificat, je peux rien y faire vu que le mien est signé par startSSL et qu’ils ne proposent que ça.
pour RC4 le mieux est d’utiliser les ciphers : “HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES” (pour nginx mais ça doit transposable)
pour le Forward Secrecy, ça dépend du logiciel de terminaison SSL que tu utilises (nginx, apache, Haproxy, pound…)
Le 10/12/2014 à 23h03
StartSSL permet normalement de signer en SHA1 ou SHA256. Et les certificats intermédiaires existent en deux versions, signés en SHA1 ou SHA256.
Il y a donc moyen d’avoir des signatures complètes en SHA256 avec StartSSL. C’est ce que j’ai sur mon serveur perso…
Le 10/12/2014 à 23h18
En parlant de startSSL, je voulais passer par leur service mais leur page d’auth ne marche pas et ça fait plusieurs années que c’est comme ça, j’ai essayé l’an passé ça me faisait pareil, je ne comprends pas…
A chaque fois quand je vais surhttps://auth.startssl.com/ j’ai droit à échec de la connexion sécurisée " /> Je me demande comment vous faites pour utiliser le service si on peut même pas s’identifier " />
Le 11/12/2014 à 00h05
Chez-moi-ça-marche, testé sous Firefox et Chromium. Ton navigateur ne remonte pas plus d’erreurs que ça ?
Le 11/12/2014 à 00h17
Je viens de voir sur un récent tuto, cette indication : Info : Pour vous authentifier, StartSSL utilise un certificat qui sera intégré à votre navigateur internet. Cette étape permet donc de générer ce certificat.
C’est peut-être pour ça que ça marche pas ? Pourtant lorsque je m’était inscrit, je n’ai pas remarqué qu’on me demandait d’installer un certif en guise de user/password…
Bon je vais refaire l’inscription, je verrais bien…
Le 10/12/2014 à 13h34
Donc c’est une faille d’implémentation et non une faille de protocole ?
Le 10/12/2014 à 13h39
D’après ce que je comprends chez Adam Langley (Monsieur SSL/TLS chez Google), ça vient plus du fait que TLS 1.0 dérive de SSLv3
However, TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine
TLS 1.2 ne semble pas concerné. (et mon site non plus " />)
Le 10/12/2014 à 13h50
Le 10/12/2014 à 13h54
Bon bin alors fausse news, si y a quelques boites qui savent pas implémenter des specs on appel pas ça une faille !
Le 10/12/2014 à 13h57
Mon site semble vulnérable. Oups. Et comme ce sont les serveurs d’OVH, j’espère qu’ils feront le nécessaire !
Le 10/12/2014 à 13h58
Oui et non, cela vient plus du fait que l’implémentation n’est pas 100% complète…
https://www.imperialviolet.org/2014/12/08/poodleagain.html
We’re removing SSLv3 in favour of TLS because TLS fully specifies the contents of the padding bytes and thus stops the attack. However, TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections.
Le 11/12/2014 à 08h09
l’inscription est à renouveler tous les deux ans, de mémoire.
Le 11/12/2014 à 21h45
“The impact of this problem is similar to that of POODLE, with the attack
being slightly easier to execute–no need to downgrade modern clients
down to SSL 3 first, TLS 1.2 will do just fine.”
Blog de Qualyshttps://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
En fait j’ai un doute, je sais pas exactement comment prendre le “just fine”, si c’est vraiment du premier degré ou non.
Sinon, la news date un peu mais il me semble que NXI n’en a pas parlé :http://www.theinquirer.net/inquirer/news/2343117/ietf-drops-rsa-key-transport-fr…
Le 11/12/2014 à 22h06
Le 11/12/2014 à 22h21
Il sera d’ailleurs intéressant de regarder en détail les certificats renvoyé par le projet “Let’s encrypt” : GitHubouhttps://letsencrypt.org/
Le 11/12/2014 à 23h01
Yup, un projet INtéressant sur le papier. Curieux de voir ce qu’en dit l’IETF également puisqu’ils prévoient d’y soumettre leur protocole
Le 15/12/2014 à 10h03
toto test 2