[Attention, comme souvent en matière de sécurité, les choses évoluent, et cet article ne sera peut-être plus à jour quand vous le lirez.]
#Poodle est une faille de sécurité dans le protocole SSL v3, publiée le 14 octobre 2014, permettant à un attaquant actif de découvrir des données chiffrées.
Poodle est officiellement CVE 2014-3566 ▻http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
Pour attaquer avec Poodle, il faut un client et un serveur #TLS (pas forcément HTTPS) qui acceptent SSL v3 (la grande majorité) et les forcer à utiliser ce vieux protocole pourri (ce qu’on nomme un repli, downgrade en franglais).
Ce forçage nécessite une attaque active (pas forcément d’être en coupure mais au moins d’être sur un réseau qui est sur le chemin entre les participants, ou de pouvoir y injecter de faux paquets). Ensuite, on peut effectuer plein de connexions en faisant varier le texte chiffré (ce qui nécessite a priori Javascript, donc fait que les clients SMTP ou IMAP sont peut-être en sécurité). Poodle permet un oracle : le serveur va petit à petit révéler le secret, si l’attaquant sait où il se trouve dans la communication (cas du cookie HTTP, ou du mot de passe SMTP).
L’attaquant n’a donc pas accès au texte en clair complet, mais il peut apprendre des secrets qui étaient dans le texte en clair.
Il faut donc impérativement débrayer SSL v3 (et cela aurait dû être fait depuis longtemps, comme recommandé par tous les bons gourous, comme le RGS de l’ANSSI). Le cas le plus urgent est celui des serveurs HTTPS, à cause du rôle de Javascript.
On peut tester si un serveur accepte SSL v3 avec SSLlabs ▻https://www.ssllabs.com/ssltest (pas mal écroulé en ce moment, avec tous les gens qui testent) ou bien en ligne de commande avec openssl s_client -ssl3 -connect HOST:PORT (qui doit échouer) ou encore nmap --script ssl-enum-ciphers -p https HOST.
À noter que certains clients sont assez bêtes pour ne pas savoir se connecter en autre chose que SSL v3, comme apparemment le client d’Atos (processeur français de paiements pour plein de banques).
Côté serveurs, les actions concrètes :
Apache avec GnuTLS : GnuTLSPriorities SECURE:-VERS-SSL3.0
Apache avec OpenSSL : SSLProtocol -SSLv3 -SSLv2
Nginx avec OpenSSL : ssl_protocols TLSv1.2 TLSv1.1 TLSv1
Postfix avec OpenSSL : smtpd_tls_protocols = !SSLv2,!SSLv3
Serveurs IMAP Dovecot : ssl_protocols = !SSLv2 !SSLv3
Serveurs IMAP Courier : TLS_PROTOCOL="TLS1_2:TLS1_1:TLS1"
Côté clients :
Les clients TLS peuvent eux-même prendre des précautions pour empêcher Poodle. Il parait qu’on peut tester sur
▻https://www.poodletest.com mais j’ai un doute (il indique un vieux Firefox comme non vulnérable). Même problème avec ▻https://sslv3.dshield.org qui affiche parfois qu’on n’est pas vulnérable même quand on l’est et parfois le contraire.
Pour Firefox : about:config > set security.tls.version.min à 1
(non testé). Ou bien cette extension Firefox, ▻https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control . Mozilla annonce le retrait de SSL v3 ▻https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0 pour les futures versions.
Pour Chrome, il faut le lancer avec la ligne de commande --ssl-version-min=tls1
Sinon, ▻http://blog.fox-it.com/2014/10/15/poodle contient une règle Snort pour détecter les connexions SSLv3. Avec tcpdump, la règle serait tcp[((tcp[12]>>4)*4)+9:2]=0x0300
Quel est le déploiement actuel de SSL v3 ? Une grande majorité ▻https://8ack.de/sslv3 des sites Web accepte toujours SSL v3. Pour les sites de e-commerce, cela s’explique par leur désir de ne pas abandonner les 1 ou 2 % d’utilisateurs qui ont
encore Internet Explorer 6. Pour les autres, il n’y a vraiment pas d’excuse. SSL v3 aurait dû être abandonné depuis au moins dix ans (TLS 1 date de 1999).
Un peu de biblio :
Article généraliste ▻http://www.wired.com/2014/10/poodle-explained Bonnes notes de synthèse courtes et directes chez Robert Graham ▻http://blog.erratasec.com/2014/10/some-poodle-notes.html Explication pointue chez Adam Langley ▻https://www.imperialviolet.org/2014/10/14/poodle.html Une autre explication technique (mais très claire) par un des auteurs ▻https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html
Un peu de technique, maintenant :
L’attaque nécessite un mode de chiffrement par blocs avec bourrage, comme CBC.
L’erreur spécifique à SSL v3 est de ne pas spécifier le contenu du bourrage. Mais une erreur plus générale de SSL et TLS est de faire MAC-then-encrypt et donc pas de « chiffrement intègre » avec les modes comme CBC. Si le RFC 7366 ►http://www.bortzmeyer.org/7366.html (Encrypt-then-MAC) avait été déployé plus tôt (bon, je trolle un peu, SSL v3 n’accepte pas les extensions), Poodle n’aurait pas été possible (voir aussi cet avis de Thomas Pornin ▻http://chat.stackexchange.com/transcript/151?m=18151930#18151930 ).
Une autre solution à Poodle serait d’interdire le repli vers le vieux protocole SSL v3. C’est ce qui est proposé dans l’Internet-Draft draft-ietf-tls-downgrade-scsv ▻https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv et mis en œuvre dans ce patch d’OpenSSL : ▻http://marc.info/?l=openssl-dev&m=141333049205629&w=2 .
