Qu’est‐ce POODLE ?
POODLE signifie Padding Oracle On Downgraded Legacy. Il s’agit d’une vulnérabilité permettant via une attaque de l’« homme du milieu » (MIM, Man In the Middle), en se plaçant entre le navigateur Web et le serveur Web, de déchiffrer les informations chiffrées.
POODLE affecte les anciennes normes de chiffrement, notamment Secure Socket Layer (SSL) version 3.0. Il n’affecte pas le mécanisme de chiffrement plus récent, et standardisé, appelé Transport Layer Security (TLS).
Recommandations
Pour atténuer cette vulnérabilité, désactivez SSL 3.0 en forçant l’utilisation de TLS, tout en vérifiant la compatibilité des navigateurs clients devant y avoir accès.
Plusieurs bulletins de sécurité ont annoncé la vulnérabilité :
- alerte CERT : http://cert.ssi.gouv.fr/site/CERTFR-2014-ALE-007/ ;
- alerte NVD : https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566.
Histoire et aides diverses
Google a identifié une faille dans le protocole SSL v3. Il existe des contournements côté serveurs comme côté clients : garder en tête la compatibilité avec les navigateurs clients. Red Hat n’a pour l’instant pas publié d’errata. Cela affecte RHEL5, RHEL6 et RHEL7, également les CentOS. À voir pour les autres distributions…
Remarque : poodle signifie caniche en anglais.
Page pour tester votre navigateur client
Tester par vous même
openssl s_client -connect mon_site:443 -ssl3
Configurer Apache
SSLProtocol All -SSLv2 -SSLv3
Configurer Postfix
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
Tester la vulnérabilité de vos sites
Voici le script proposé par Red Hat :
#!/bin/bash
#
# Copyright (C) 2014 by Dan Varga <dvarga@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
host=$1
port=$2
if [ "$2" == "" ]
then
port=443
fi
out="`echo x | timeout 5 openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?
if [ $ret -eq 0 ]
then
echo "VULNERABLE! SSLv3 detected."
exit
elif [ $ret -eq 1 ]
then
out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`
if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ]
then
echo "Not Vulnerable. We detected that this server does not support SSLv3"
exit
fi
elif [ $ret -eq 124 ]
then
echo "error: timeout connecting to host $host:$port"
exit
fi
echo "error: Unable to connect to host $host:$port"
Aller plus loin
- OpenSSL décrit POODLE (229 clics)
- Préconisation Red Hat (183 clics)
- Détection de la faille proposée par Red Hat (145 clics)
- Piqûre de rappel TLS (277 clics)
- Explication claire en français (680 clics)
# Précision que le `DLE` de `POODLE`
Posté par Burps . Évalué à 9.
Je pense qu'il manque une information sur cette attaque. Le Padding Oracle est sur SSL3.0. le Downgraded Legacy vient du comportement des clients. Le scénario est le suivant:
Pour éviter ce scénario, une cipher suite vide a été rajoutée: TLS Fallback Signaling Cipher Suite Value (SCSV). Cf
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
# Quelques ressources supplémentaires sur le sujet
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
Pour savoir si un serveur accepte encore SSLv3, il y a par exemple la commande openssl citée ci-dessus, on peut aussi utiliser nmap :
nmap --script ssl-enum-ciphers -p https HOST
Un point sur lequel on n'insiste peut-être pas assez : ce problème n'est pas un bogue logiciel, pas un problème d'implémentation, mais bien un problème dans le protocole lui-même !
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Burps . Évalué à 4.
La partie MIM, quand même, personne n'obligeait les clients à se reconnecter en demandant SSL3.0, même si d'un point de vue client, être utilisable est prioritaire (TLS propose maintenant un mécanisme pour se protéger lorsqu'on désire avoir ce comportement, mais ce n'est pas un comportement impliqué par le protocole à mon avis).
Pour la partie Padding Oracle, c'est en effet intrinsèque. Mais là, pas de surprise non plus. On sait maintenant que Mac-then-Encrypt est problématique. Je suis même étonné que cette attaque ne sort que maintenant.
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Zenitram (site web personnel) . Évalué à 2.
Pareil.
en fait, je me demande où est la "nouveauté" : par design (partie non authetifiée, dont l'intégrité sur qui cause n'est pas testée, donc il modifie tout ce qu'il veut), un MITM peut choisir le protocole à utiliser en refusant les protocoles "trop sécurisés" et c'est le client qui passe de lui-même en une version plus faible.
Le problème vient donc "juste" que SSLv3 est plus ou moins (il faut du temps quand même) troué est qu'il peut toujours être utilisé (il est accepté autant côté client que serveur), et donc ce problème apparait automatiquement (par design) dès qu'on a su que SSLv3 avait un problème.
La nouveauté est-elle que quelqu'un a regardait comment fonctionnait la phase de négociation du protocole et s'en rendu compte que n'importe quel MITM peut choisir le protocole utilisé? C'est gros (car c'est assez basique), sutout qu'on aura alors exactement le même problème quand on aura TLSv2.0 et que TLSv1.x sera troué : qu'est-ce qui est prévu pour ne pas avoir le même problème plus tard? On redécouvrira cette faille de la négociation à ce moment-la (est-ce que TLSv1.3 a un mécanisme pour détecter que c'était pas le protocole qui été préféré par le client)?
Ou alors, j'ai loupé un passage du problème, je n'arrive pas à comprendre. Quelqu'un pour expliquer en quoi ça ne fait pas partie du design de l'initialisation HTTPS qu'un MITM puisse décider quel protocole utiliser (quel mécanisme est mis en oeuvre pour sécuriser la liste des protocoles supportés qui est envoyée au serveur, et qui est ici cassé)?
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
Concernant la rétrogradation de protocole, il y a ça : https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ qui est utilisé par OpenSSL dans le jeu de mises à jour de sécurité livré mercredi (https://www.openssl.org/news/secadv_20141015.txt). Mais encore à l’état de brouillon.
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Zenitram (site web personnel) . Évalué à 3.
Si j'ai bien compris (mais je suis vraiment pas à l'aise, n'hésitez pas à me corriger), c'est un ajout au protocole, donc tous les clients et serveurs actuels ne pourront pas tester, et il faut que les deux supportent cette extension, si un seul ça ne marche pas, exact?
On parle quand même d'IE6 dans l'histoire (le seul encore dans la nature qui ne supporte pas TLS), donc des produits qui n'ont plus aucun support et donc aucune mise à jour, pas sûr qu'IE7 (TLS1.0) sera mis à jour…
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Kioob (site web personnel) . Évalué à 1.
Si j'ai bien compris, pour cette fois c'est effectivement mort. Donc le cas d'IE6 me semble tranché.
Mais cette faille met en évidence le problème que pose le «fallback» SSL/TLS de manière générale, et donc oui il est important d'y trouver une solution.
En effet TLS 1.0 est lui aussi sensible à certaines attaques (BEAST par exemple), à priori de moins grande envergure, et il est dommage qu'il «suffise» de forcer les clients compatibles TLS 1.2 à basculer sur ce protocole.
alf.life
[^] # Re: Quelques ressources supplémentaires sur le sujet
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
Pour la faille actuelle, ça ne sert pas à grand chose sur les vieux systèmes puisqu’il faut en effet que client et serveur prennent en charge cette nouvelle extension (implémentée côté client comme un nouvel algorithme de chiffrement ajouté à la suite des autres). Par contre, elle devrait répondre à ta question concernant le futur passage à TLSv1.3 ou TLSv3, tant que la validation des messages
ChangeCipherSpec
etFinished
n’est pas cassée (ils permettent de confirmer au pair que la poignée de main initiale et notamment la suite d’algorithmes de chiffrements supportés n’a pas été modifiée par un MITM).Pour IE6 et SSLv3, je crois qu’il n’y a plus rien à faire, SSLv3 était déjà connu pour ne pas être solide, là, c’est certainement le coup de grâce…
# Configurer Dovecot
Posté par jihele . Évalué à 8.
Dans conf.d/10-ssl-conf
ssl_protocols = !SSLv2 !SSLv3
# Mozilla
Posté par Spack . Évalué à 9.
A noter, l'excellent article sur le Wiki de Mozilla pour bien configurer son serveur Web.
https://wiki.mozilla.org/Security/Server_Side_TLS
Et en bonus, une petite commande pour avoir la liste des protocoles SSL utilisés en utilisant
nmap
:[^] # et aussi
Posté par AgentSteel (site web personnel) . Évalué à 3.
cet article :
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
qui est régulièrement mis à jour (pour Apache, nginx…)
[^] # Re: Mozilla
Posté par jve (site web personnel) . Évalué à 7.
Je suis l'auteur du wiki de Mozilla. Merci pour la référence :)
A voir aussi, l'outil cipherscan écrit pour rapidement lister les paramètres d'une connexion TLS. Moins poussé que SSL Labs, mais en console et plus rapide.
```
$ git clone https://github.com/jvehent/cipherscan.git && cd cipherscan && ./cipherscan google.com
……………….
Target: google.com:443
prio ciphersuite protocols pfs_keysize
1 ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 ECDH,P-256,256bits
2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits
3 ECDHE-RSA-AES128-SHA TLSv1.1,TLSv1.2 ECDH,P-256,256bits
4 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
5 AES128-GCM-SHA256 TLSv1.2
6 AES128-SHA256 TLSv1.2
7 AES128-SHA TLSv1.1,TLSv1.2
8 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
9 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2
10 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits
11 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits
12 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
13 AES256-GCM-SHA384 TLSv1.2
14 AES256-SHA256 TLSv1.2
15 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
16 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits
17 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,P-256,256bits
18 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2
Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: 100800
OCSP stapling: not supported
Server side cipher ordering
```
[^] # Re: Mozilla
Posté par jve (site web personnel) . Évalué à 5.
Cipherscan contient également un script d’analyse des configuration pour aider a atteindre les trois niveaux proposes sur le wiki:
A noter que Google.com maintient la compatibilité avec les vieux clients, comme windows XP pre-SP3 et java6, ce qui explique la présence de SSLv3, RC4 et un certificat a signature SHA-1.
[^] # Re: Mozilla
Posté par neitsab . Évalué à 4.
Merci à toi pour ce wiki, j'ai récemment mis en place mon premier serveur et j'étais justement en recherche de bonnes pratiques pour sécuriser nginx ! C'est génial de la part de Mozilla de partager ses recommandations (et de manière aussi détaillée), ça permet aux personnes qui n'ont pas l'expérience d'avoir un référentiel sur lequel s'appuyer : en effet quand on ne s'y connaît pas, il est pour le moins ardu de trouver une réponse qui fasse autorité parmi toutes les préconisations présentes sur le web…
En parlant de bonnes pratiques : j'ai remarqué que dans l'exemple de configuration pour nginx donné sur le wiki, la directive
ssl on;
est utilisée. Or ayant justement récemment regardé la documentation officielle, il se trouve que celle-ci est considérée obsolète ; à la place il est recommandé d'utiliser le paramètressl
de la directivelisten
. Je ne pense pas que cela change grand chose en termes de sécurité, mais ça fait toujours gagner une ligne…;-)
# ProFTPd, NGinx
Posté par Adminrezo (site web personnel) . Évalué à 2.
Configurer ProFTPd
TLSProtocol TLSv1
Configurer NGinX
ssl_protocols -SSLv2 -SSLv3 TLSv1;
[^] # Re: ProFTPd, NGinx
Posté par Adminrezo (site web personnel) . Évalué à 2.
Configurer OpenLDAP
TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:!SSLv3
[^] # Re: Minepeon
Posté par voxmundix . Évalué à 2. Dernière modification le 17 octobre 2014 à 14:05.
Pour sécuriser le serveur de minepeon (arch):
sudo nano /etc/httpd/conf/extra/httpd-ssl.conf
Ajouter "SSLProtocol all -SSLv3" juste après "SSLEngine on" puis redémarrer.
[^] # Re: ProFTPd, NGinx
Posté par Misc (site web personnel) . Évalué à 4.
J'ai du mal à piger en quoi une attaque qui requiert que l'attaquant fasse des requetes actives ( ie, la partie ou le js intervient dans le papier ) va marcher pour openldap ?
Quel client va poser souci, dans quels conditions ?
[^] # Re: ProFTPd, NGinx
Posté par ianux (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 17 octobre 2014 à 18:18.
Configurer Nginx
Attention, les versions récentes de Nginx semblent ne plus supporter la soustraction de protocole mais uniquement l'explicitation (voir http://nginx.org/en/docs/http/configuring_https_servers.html). La bonne ligne serait donc :
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
[^] # Re: ProFTPd, NGinx
Posté par Antoine . Évalué à 3.
C'est un peu bête, parce que le jour où TLS 1.3 est supporté par ta bibliothèque de crypto, tu n'en tires partie qu'à la condition de penser à modifier ton fichier de conf…
[^] # Re: ProFTPd, NGinx
Posté par neitsab . Évalué à 0.
Es-tu sûr que l'adjonction d'un
-
devant les protocoles à exclure soit la bonne manière de faire ?À la limite ajouter un
!
devant comme pour ssl_ciphers, pourquoi pas, mais le plus simple ne serait-il pas de tout simplement mentionner uniquement les protocoles acceptés ? Et d'ailleurs, pourquoi exclureTLSv1.1
etTLSv1.2
, qui sont les seuls à atténuer le risque d'attaque BEAST ?[^] # Re: ProFTPd, NGinx
Posté par neitsab . Évalué à 0.
J'ai pris trop de temps pour éditer mon commentaire, le vilain sorcier de la page d'erreur m'a repoussé…
L'édit que je voulais faire :
J'aurais dû lire tous les commentaires, ianux répond déjà à ce sujet (et en plus le point d'exclamation dans les paramètres de
ssl_ciphers
semble être lié au format compris par openSSL).À tester : ajouter
TLSv1.3
à la directive pour anticiper… Mais pas sûr que nginx accepte de se lancer s'il détecte une anomalie dans sa config (ça m'est arrivé pour moins que ça). Pour tester :$ nginx -t
.[^] # Re: ProFTPd, NGinx
Posté par KiKouN . Évalué à 2.
Cela ne résous pas le problème, On ne peut prédire les numéro de version de TLS pour les 10 ans à venir.
[^] # Re: ProFTPd, NGinx
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Mes fichiers de conf sont gérés par cfengine… Je fais un coup de sed lorsqu'il faut durcir la configuration de temps en temps et hop, c'est validé puis déployé (et versionné). Imaginer une conf qui puisse tenir 10 ans me semble une idée plus que fumeuse ;-)
[^] # Re: ProFTPd, NGinx
Posté par Kwiknclean . Évalué à 1.
Je ne comprends pas j'ai effectué les modifications dans Nginx.
Dans le cas ou l'on met TLSv1.3 effectivement il rale au check.
En testant après modification avec le script fournit par Red Hat …
Depuis l'extérieur :
~$ ./test-poodle.sh www.pentakonix.fr 443
VULNERABLE! SSLv3 detected.
Hein ?!
# Script
Posté par claudex . Évalué à 5.
Le script proposé n'est pas très pratique pour tester STARTTLS, du coup, j'ai fais un petit script en Python qui test SMTP, IMAP, POP, HTTPS sur l'hôte donnés (et on peut même spécifier un réseau pour tester tous les hôtes). C'est loin d'être parfait mais ça permet de faire le tour rapidement. Si vous avez des idées de ports à ajouter, n'hésitez pas. https://github.com/claudex/test-ssl
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Routeur
Posté par voxmundix . Évalué à 1. Dernière modification le 19 octobre 2014 à 15:44.
Les routeurs de belgacom (bbox2 je crois) sont faillible (ça ne m'étonne même pas…):
[^] # Re: Routeur
Posté par claudex . Évalué à 4.
ça reste un service accessible uniquement en interne. Ça ne me semble pas si grave que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Routeur
Posté par voxmundix . Évalué à 2.
Non tu peux tout a fait activer l'accès externe a l'interface d'administration (je pense que c'est pour cela que le NAT de belgacom bloque la redirection des ports 80 et 443).
Mais si non pour les attaques MITM en interne bah c'est un moyen comme un autre de choper un accès admin au routeur. (bon reste a voir quel proportion d'utilisateur utilise https au lieu de http)
[^] # Re: Routeur
Posté par claudex . Évalué à 4.
Je doute que ce soit très utilisé, et si tu en as absolument besoin, tu peux désactivé SSLv3 sur ton navigateur.
Vu que le certificat génère un gros warning sur les navigateurs, je doute que ceux qui y accède en https se rendent compte d'une attaque MitM si le certificat est différent. Du coup, ça me semble une attaque bien plus simple qu'utiliser Poodle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# script de test
Posté par Frogg . Évalué à 0. Dernière modification le 20 octobre 2014 à 11:58.
voici le script de Dan Varga modifié, pour être plus simple à l'utilisation et à la lecture
Script call = bash poodle.sh {serverIP} {serverPort}
# Pour désactiver SSL 3.0 dans votre firefox
Posté par Xavier Poinsard . Évalué à 1.
En attendant la version 34 (pour le 25 novembre), une extension permet de désactiver SSLv3 :
https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.