ietf-tls-downgrade-scsv-00 - TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks

/draft-ietf-tls-downgrade-scsv

  • [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 .