La faille Poodle exploitable avec TLS dans certains cas

La faille Poodle exploitable avec TLS dans certains cas

The Neverending Story

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

10/12/2014 3 minutes
28

La faille Poodle exploitable avec TLS dans certains cas

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.

 

poodle tls nxi

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.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Poodle, de SSL à TLS

En cas de vulnérabilité, l'attaque est plus simple à mettre en place 

Des correctifs à appliquer

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (28)


Donc c’est une faille d’implémentation et non une faille de protocole ?


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 <img data-src=" />)








kypd a écrit :



Donc c’est une faille d’implémentation et non une faille de protocole ?



Définitivement une faille d’implémentation : Une non vérification du padding qui est maintenant spécifié dans TLS



Bon bin alors fausse news, si y a quelques boites qui savent pas implémenter des specs on appel pas ça une faille !


Mon site semble vulnérable. Oups. Et comme ce sont les serveurs d’OVH, j’espère qu’ils feront le nécessaire !


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.





En cas de vulnérabilité, l’attaque est plus simple à mettre en place





<img data-src=" />





  • En cas de pluie, on est plus facilement mouillé

  • Quand il fait chaud, on transpire plus facilement




En effet


Sinon tu peux lire aussi la phrase en entier <img data-src=" />








benjarobin a écrit :



Définitivement une faille d’implémentation : Une non vérification du padding qui est maintenant spécifié dans TLS





Si c’est une faille d’implémentation, il suffi de la corriger. Je ne vois donc pas en quoi ce serait “définitif”…



Tu ne serais pas en train d’employer le mot “définitivement” comme traduction du mot “definitely” par hasard ? <img data-src=" />



Eventually <img data-src=" />








kypd a écrit :



Bon bin alors fausse news, si y a quelques boites qui savent pas implémenter des specs on appel pas ça une faille !





Vrai problème. On ne peut pas parler de fausse news. <img data-src=" />



C’est la phrase complète (titre du paragraphe) <img data-src=" />



Je taquine


<img data-src=" /><img data-src=" /><img data-src=" />


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 -&gt; http. Il y a pas un loup là ?

Perso ça me donne pas envie de lire la suite de l’article !


Le “www” n’est pas prévu pour du https, donc effectivement redirection.

Le “compte” est en https.


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 ?


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…)


StartSSL permet normalement de signer en SHA1 ou SHA256. Et les certificats intermédiaires existent en deux versions, signés en SHA1 ou SHA256.



&nbsp;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…


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 <img data-src=" /> Je me demande comment vous faites pour utiliser le service si on peut même pas s’identifier <img data-src=" />


Chez-moi-ça-marche, testé sous Firefox et Chromium. Ton navigateur ne remonte pas plus d’erreurs que ça ?


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…


l’inscription est à renouveler tous les deux ans, de mémoire.





kankan_01 a écrit :



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…





ha? je ferais attention lors du renouvellement de mon certificat, mais je n’avais pas vu ça la dernière fois. <img data-src=" />



“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…








Florent_ATo a écrit :



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…







Je l’avais raté aussi. Une généralisation de la Perfect Forward Secrecy c’est toujours ça de pris.



Et si les marchands de tapis certificats pouvaient se bouger les fesses et accélérer la distribution de certificats issus de clés générées avec ECDSA, ça serait encore mieux







geekounet85 a écrit :



j’avais les mêmes

pour RC4 le mieux est d’utiliser les ciphers : “HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES” (pour nginx mais ça doit transposable)







Oui, ce sont des listes propres à OpenSSL. Donc tout logiciel utilisant la bibliothèque de ce dernier doit comprendre ce type de syntaxe (testé avec Apache, Postfix et Proftp et aucun soucis à chaque fois). En revanche GnuTLS a une syntaxe différente



Perso j’utilise “ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:”, pas encore eut de soucis



Il sera d’ailleurs intéressant de regarder en détail les certificats renvoyé par le projet “Let’s encrypt” :https://github.com/letsencrypt/lets-encrypt-preview ouhttps://letsencrypt.org/


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


toto test 2