POODLE

février 27, 2015  |   Actualités,Blog   |     |   0 commentaire

Introduction

Peut-être avez vous rencontré récemment une page d’erreur lors du chargement d’une page utilisant SSL/TLS ressemblant à ceci :

Capture d'écran de l'erreur "No ciphers match"

Capture d’écran de l’erreur « No ciphers match »

 

Nous allons voir au travers de cet article la raison de l’apparition récente de cette page sur nos navigateurs.

SSL_error_no_cypher_overlap

Ce message d’erreur est généré par le code  SSL et apparait

  • soit lorsque les négociations entre le navigateur et le serveur ne parviennent pas à déterminer un cipher commun,
  • soit lors d’une incompatibilité entre les versions de SSL/TLS.

Si nous regardons les captures de paquets de la négociation SSL, nous obtenons ceci coté navigateur :

poodle-client

Et ceci coté serveur :

poodle-server

Nous nous apercevons alors que le ciphersuite 0x000a choisi est commun aux  deux propositions. Le message d’erreur est donc dû au second cas “incompatibilité avec les versions de SSL/TLS”.

Effectivement, suite à la faille Poodle [1] (Padding Oracle On Downgraded Legacy Encryption) publiée le 14 octobre 2014, les grands navigateurs tels que Mozilla Firefox [2] et Google Chrome [3] ont désactivé la dernière version de SSLv3 sortie en Novembre 1996.

Cette faille s’applique aux ciphers utilisant le mode CBC (c’est-à-dire le chiffrement par blocs) [4] et plus particulièrement à son bourrage non déterministe. En effet, le mode CBC ne chiffrant uniquement que des blocs de longueurs fixes, il est nécessaire parfois d’allonger (i.e “bourer”) le dernier bloc à chiffrer. Toutefois, SSLv3 ne précise pas le contenu de cet ajout ce qui permet à l’attaquant de le modifier et donc, par exemple, de recopier un précédant bloc à la place du dernier (celui contenant le bourrage). Il aura alors une chance sur 256 que la longueur du bourrage coïncide avec le dernier octet. De cet façon le destinataire acceptera le bloc. L’attaquant pourra ainsi répéter l’opération en allongeant contenu du bloc et le déchiffrer octet par octet.

A l’inverse, TLS annonce le contenu du bourrage qu’il utilise, et de ce fait, les chances pour l’attaquant de trouver un bloc qui peut être interchangé avec le bloc bourré est drastiquement réduit.

Cette attaque se déroule suivant la méthode du Man In The Middle (où l’attaquant se place entre un serveur et ses clients) en forçant ces derniers à utiliser SSLv3 via la méthode du Downgrade Dance (fait de faire croire à un serveur que nous ne supportons que le SSLv3 que nous savons vulnérable) afin d’utiliser la méthode pré-citée.

Conséquence et parade

Les conséquences et les parades de cette faille sont très liées. En effet, il suffit de désactiver purement et simplement SSLv3 afin qu’elle ne soit plus exploitable car cela forcera l’utilisation de TLS.

Toutefois, tous les sites utilisant toujours SSLv3 (au plus), deviendront alors inaccessibles avec les navigateurs n’implémentant  que TLS. C’est le cas pour de nombreux outils tels que le Webmail Lotus Domino [5] pour lequel IBM a dû sortir un patch ou certains équipementiers tels que APC [6].

Cette faille à permis de revoir la façon dont les négociations TLS se déroulent. Alors que TLS était également vulnérable  dans le cadre d’une Downgrade Dance, il est désormais recommandé de configurer les clients avec l’option TLS_FALLBACK_SCSV. Ainsi lors de l’établissement de la session TLS, ce sont les versions décroissantes de TLS qui sont proposées.. De cette manière, si la connexion échoue en TLS1.2, elle pourrait s’établir en TLS1.0 et non en SSLv3 directement.

Il est aussi recommandé de configurer les serveurs (en mettant à jour OpenSSL avec une version compatible et en redémarrant le serveur Web uniquement) pour, lors de la tentative de connexion d’un client avec l’option TLS_FALLBACK_SCSV, refuser d’établir un canal sécurisé si le client ne possède pas une version de TLS au moins équivalente à celle du serveur.

Conclusion

Si vous êtes confrontés à une erreur lors de l’accès à un site utilisant SSL/TLS et que cette erreur porte un message du type “cipher or ssl version mismatch” vous êtes probablement en train d’essayer d’accéder à un serveur qui utilise SSLv3 (ou sous le coup d’une attaque). Si vous regardez les ciphers proposés par les deux parties, vous vous rendrez probablement compte qu’il y a des correspondances mais que l’une des parties (vraisemblablement votre navigateur) affiche une version en TLS alors que l’autre (le serveur) affichera SSLv3. A l’heure de la rédaction de cet article il existe la solution de contournement d’utiliser Internet Explorer (mais vous serez vulnérable à une attaque), sinon il vous faudra être patient et attendre que l’éditeur ou l’administrateur du site fasse la mise à jour afin de passer ses services en TLS.

Bibliographie

[1] https://www.openssl.org/~bodo/ssl-poodle.pdf

[2] https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

[3] https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Vnhy9aKM_l4

[4] https://www.imperialviolet.org/2014/10/14/poodle.html

[5] http://www-01.ibm.com/support/docview.wss?uid=swg21687167

[6] http://www.apc.com/support/getPDF.do?id=FA238115&version=3.0&country=ITB&lang=en&locale=en_US

[7] http://en.wikipedia.org/wiki/POODLE

[8] http://www.nextinpact.com/news/90427-la-faille-poodle-sslv3-permet-decrypter-donnees-sur-connexion.htm