Comment corriger / contourner la vulnérabilité SSLv3 POODLE (CVE-2014-3566)?

158

Après l'attaque BEAST et Bug Heartbleed , j'ai maintenant entendu parler d'une nouvelle vulnérabilité dans SSL / TLS appelée POODLE . Comment puis-je me protéger contre l'exploitation?

  • Seuls les serveurs ou les clients sont-ils affectés?
  • Est-ce spécifique à OpenSSL / GnuTLS?
  • Quels types de services sont affectés? Seulement HTTPS ou aussi IMAPS, SMTPS, OpenVPN, etc.?

Veuillez me montrer des exemples sur la façon d’éviter cette vulnérabilité.

    
posée gertvdijk 15.10.2014 - 01:49
la source

4 réponses

210

Informations générales

SSL est conçu pour sécuriser le niveau de transport sur Internet. Pour le Web, alias HTTP, vous le saurez en tant que HTTPS, mais il est également utilisé pour d’autres protocoles d’application. SSLv2 était le premier protocole de sécurité des transports largement utilisé, mais peu de temps après. Les successeurs SSLv3 et TLSv1 sont maintenant largement supportés. TLSv1.1 et TLSv1.2 sont plus récents et prennent également beaucoup de support. La plupart des navigateurs Web publiés en 2014, sinon tous, sont pris en charge.

La récente découverte par les ingénieurs de Google montre que SSLv3 ne devrait plus être utilisé (comme SSLv2 est obsolète depuis longtemps). Les clients qui ne pourront pas se connecter à votre site / service sont probablement très limités. CloudFlare a annoncé que moins de 0,09% de ses visiteurs comptent toujours sur SSLv3.

Solution simple: désactiver SSLv3.

Ubuntu fournit-il des mises à jour?

Oui, via usn-2385-1 avec l’ajout de la fonctionnalité SCSV, mais cela n'atténue pas complètement le problème , car il ne désactive pas SSLv3 et le correctif ne fonctionnera que si les deux côtés de la connexion ont été corrigés. Vous le recevrez via vos mises à jour de sécurité régulières dans votre gestionnaire de paquets.

Alors, VOUS devez toujours agir vous-même pour désactiver SSLv3 (il est configurable). Les futures versions des clients / navigateurs désactiveront probablement SSLv3. Par exemple. Firefox 34 le fera.

Désactiver complètement SSLv3 par défaut au niveau de l’implémentation dans Ubuntu va probablement casser des choses là aussi pour une utilisation non-HTTPS SSL qui est moins vulnérable, donc je suppose que les responsables ne le feront pas et que seul ce patch SCSV sera appliqué.

Pourquoi la mise à jour SCSV d’OpenSSL via usn-2385-1 n’atténue-t-elle pas le problème?

Vraiment, arrêtez de poser de telles questions et passez simplement quelques paragraphes et désactivez SSLv3. Mais bon, si vous n'êtes pas convaincu, vous voilà:

POODLE montre que SSLv3 avec les chiffrements CBC est cassé, l'implémentation de SCSV ne change rien à cela. SCSV garantit uniquement que vous ne passerez pas de certains protocoles TLS à un protocole TLS / SSL inférieur à celui requis avec l'attaque Man-in-the-Middle requise pour les cas habituels.

Si vous devez accéder à un serveur qui n’offre pas du tout de TLS, mais uniquement à SSLv3, votre navigateur n’a pas vraiment le choix et doit communiquer avec le serveur à l’aide de SSLv3, qui est alors vulnérable sans attaque de mise à niveau inférieur .

Si vous devez accéder à un serveur qui offre TLSv1 + et SSLv3 (ce qui est déconseillé) et que vous voulez être sûr que votre connexion ne sera pas rétrogradée vers SSLv3 par un attaquant, alors les deux le serveur et le client a besoin de ce patch SCSV.

Pour atténuer complètement le problème de la désactivation de SSLv3, votre fin est suffisante et vous pouvez être sûr que vous ne serez pas rétrogradé. Et vous ne pourrez pas communiquer avec les serveurs SSLv3 uniquement.

OK, comment puis-je désactiver SSLv3?

Voir ci-dessous dans les sections spécifiques à l'application: Firefox, Chrome, Apache, Nginx et Postfix sont couverts pour l'instant.

Seuls les serveurs ou les clients sont-ils affectés?

La vulnérabilité existe si le serveur et le client acceptent SSLv3 (même si les deux sont capables de TLSv1 / TLSv1.1 / TLS1.2 en raison d’une attaque de rétrogradation).

En tant qu'administrateur du serveur, vous devez désactiver SSLv3 maintenant pour la sécurité de vos utilisateurs.

En tant qu’utilisateur, vous devez désactiver SSLv3 dans votre navigateur maintenant pour vous protéger lorsque vous visitez des sites Web qui prennent toujours en charge SSLv3.

Cet OpenSSL / GnuTLS / navigateur est-il spécifique?

Non. C'est un bogue de protocole (design), pas un bogue d'implémentation. Cela signifie que vous ne pouvez pas vraiment le corriger (sauf si vous modifiez la conception de l’ancienne version de SSLv3).

Et oui, il y a une nouvelle version de sécurité OpenSSL , mais lisez ci-dessous ( mais je vraiment besoin du support SSLv3 ... pour la raison X, Y, Z! ) sur les raisons pour lesquelles vous devriez vous concentrer sur la désactivation totale de SSLv3.

Puis-je tuer SSLv3 au niveau du réseau (pare-feu)?

Eh bien, oui, probablement. Je mets ceci dans un billet de blog séparé pour d'autres réflexions et travaux. Nous pouvons avoir une règle magique iptables que vous pouvez utiliser!

Mon article de blog: Comment supprimer SSLv3 sur votre réseau en utilisant iptables pour POODLE?

Est-ce pertinent pour HTTPS uniquement ou également pour IMAP / SMTP / OpenVPN et d'autres protocoles avec prise en charge SSL?

Le vecteur d’attaque actuel, comme l’ont montré les chercheurs, fonctionne en contrôlant le texte en clair envoyé au serveur en utilisant Javascript sur la machine de la victime. Ce vecteur ne s'applique pas aux scénarios non HTTPS sans utiliser de navigateur.

Par ailleurs, normalement, un client SSL ne permet pas de rétrograder la session vers SSLv3 (TLSv1 + étant visible dans les fonctions de prise de contact), mais les navigateurs veulent être très rétrocompatible et le font. La combinaison avec le contrôle du texte en clair et la manière spécifique dont un en-tête HTTP est construit le rendent exploitable.

Conclusion: désactivez SSLv3 pour HTTPS maintenant , désactivez SSLv3 pour les autres services de votre prochaine fenêtre de service.

Quel est l'impact? Dois-je révoquer et régénérer mon certificat de serveur? (Comme avec Heartbleed)

Non, vous n'avez pas besoin de faire pivoter vos certificats pour cela. La vulnérabilité expose la récupération de texte en clair à partir des données de session, elle ne donne accès à aucun secret (ni la clé de session ni la clé de certificat).

Un attaquant est très probablement uniquement capable de voler les en-têtes de texte en clair comme les cookies de session afin d'effectuer des piratage de session . Une contrainte supplémentaire est la nécessité d’une attaque MitM complète (active).

Est-ce que je peux faire autre chose pour améliorer ma configuration SSL en général?

En tant qu’utilisateur, en plus de désactiver SSLv3 dans votre navigateur, pas vraiment. Eh bien, installez toujours les dernières mises à jour de sécurité.

Pour les serveurs, suivez le guide du serveur TLS de Mozilla . Et testez avec le test SSL Labs de Qualys . Ce n'est vraiment pas si difficile d'obtenir une note A + sur votre site. Mettez simplement à jour vos paquets et implémentez les recommandations du guide de Mozilla.

Mais j'ai vraiment besoin du support SSLv3 ... pour la raison X, Y, Z! Maintenant quoi?

Eh bien, il existe un correctif qui contourne l'attaque de mise à niveau inférieur des clients compatibles TLSv1, appelée protection de secours SSLv3. Cela améliorera également la sécurité de TLSv1 + (l'attaque est plus difficile / impossible). Il est proposé en tant que backport à partir d’une version plus récente d’OpenSSL dans l’avis de sécurité Ubuntu usn-2385-1 . .

Big catch: les clients et les serveurs ont besoin de ce correctif pour fonctionner. Donc, à mon avis, lorsque vous mettez à jour à la fois les clients et les serveurs, vous devez simplement passer à TLSv1 + de toute façon.

Cependant, s'il vous plaît, veuillez simplement retirer SSLv3 de votre réseau pour le moment. Efforcez-vous de mettre à niveau les normes de sécurité et abandonnez simplement SSLv3.

J'ai entendu parler de la prise en charge de SCSV pour éliminer l'attaque de dégradation de protocole. En ai-je besoin?

Seulement si vous avez vraiment besoin de SSLv3 pour une raison quelconque, mais cela améliore également la sécurité dans TLSv1 +, alors oui, je vous recommande de l'installer. Ubuntu fournit une mise à jour pour cette fonctionnalité dans usn-2385-1 . Vous le recevrez via vos mises à jour de sécurité régulières dans votre gestionnaire de paquets.

Tester la vulnérabilité de sites hébergés de manière privée (par exemple, intranet / hors ligne).

Vos serveurs sont vulnérables simplement s’ils prennent en charge SSLv3. Plusieurs options ici:

  • Avec OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Si la connexion réussit, sslv3 est activé. S'il échoue, il est désactivé. Quand il échoue, vous devriez voir quelque chose comme:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Utilisation de nmap :

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Il devrait sortir ' SSLv3: No supported ciphers found '. Ajustez pour votre nom d'hôte / port.

  • Utilisation de cipherscan . Cloner / télécharger le binaire et l'exécuter:

    ./cipherscan myhostname.tld
    

    Il ne devrait pas lister quoi que ce soit avec SSLv3 dans la colonne "Protocols".

Navigateur Firefox

Ouvrez about:config , recherchez security.tls.version.min et définissez la valeur sur 1 . Ensuite, redémarrez votre navigateur pour supprimer les connexions SSL ouvertes.

Firefox à partir de la version 34 désactive SSLv3 par défaut et ne nécessite donc aucune action ( source ). Cependant, au moment de la rédaction, 33 vient de sortir et 34 est prévu pour le 25 novembre.

Google Chrome (Linux)

Modifiez le fichier /usr/share/applications/google-chrome.desktop , par exemple

sudo nano /usr/share/applications/google-chrome.desktop

Modifiez toutes les lignes en commençant par Exec= pour inclure --ssl-version-min=tls1 .

E.g. une ligne comme

Exec=/usr/bin/google-chrome-stable %U

devient

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Assurez-vous ensuite de fermer complètement le navigateur (les applications Chrome peuvent garder votre navigateur actif en arrière-plan!).

Remarque: vous devrez peut-être répéter chaque mise à jour du package Google Chrome, en remplaçant ce fichier .desktop lanceur. Un navigateur Google Chrome ou Chromium avec SSLv3 désactivé par défaut n’a pas encore été annoncé au moment de la rédaction du présent document.

Serveur HTTP Apache

Si vous utilisez un serveur Web Apache qui autorise actuellement SSLv3, vous devrez modifier la configuration Apache. Sur les systèmes Debian et Ubuntu, le fichier est /etc/apache2/mods-available/ssl.conf . Sur CentOS et Fedora, le fichier est /etc/httpd/conf.d/ssl.conf .Vous devrez ajouter la ligne suivante à votre configuration Apache avec d'autres directives SSL.

SSLProtocol All -SSLv2 -SSLv3

Cela autorisera tous les protocoles sauf SSLv2 et SSLv3.

Pendant que vous y êtes, vous pouvez envisager d'améliorer la configuration de la suite de chiffrement de votre serveur Web, comme expliqué dans le serveur TLS de Mozilla. guide . Ajouter par exemple:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Vérifiez ensuite si la nouvelle configuration est correcte (pas de fautes de frappe, etc.):

sudo apache2ctl configtest

Et redémarrez le serveur, par exemple

sudo service apache2 restart

Sur CentOS et Fedora:

systemctl restart httpd

Plus d’informations: Documentation Apache

Maintenant, testez-le: si votre site est accessible au public, testez-le à l'aide de l'outil SSL Labs de Qualys .

Serveur Nginx

Si vous utilisez Nginx, incluez simplement la ligne suivante dans votre configuration parmi les autres directives SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Pendant que vous y êtes, vous pouvez envisager d’améliorer la configuration de la suite de chiffrement de votre serveur Web, comme expliqué dans le serveur TLS de Mozilla. guide . Ajouter par exemple:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

Et redémarrez le serveur, par exemple

sudo service nginx restart

Référence: documentation Nginx

Maintenant, testez-le: si votre site est publiquement disponible, testez-le à l'aide de l'outil SSL Labs de Qualys .

serveur web Lighttpd

Les versions Lighttpd & gt; 1.4.28 prennent en charge une option de configuration pour désactiver SSLv2 et v3. Les versions de Lighttpd antérieures à 1.4.28 vous permettent de désactiver SSLv2 UNIQUEMENT. Veuillez noter qu'Ubuntu 12.04 LTS et les versions antérieures installent au mieux lighttpd v1.4.28 et qu'une correction simple n'est donc pas disponible pour ces distributions. Par conséquent, ce correctif ne doit être utilisé que pour les versions Ubuntu supérieures à 12.04.

Pour Ubuntu version 12.04 ou Debian 6, un package lighttpd mis à jour est disponible dans le dépôt openSUSE: lien

Le paquet est destiné à Debian 6 (Squeeze) mais fonctionne également le 12.04 (précis)

Modifiez votre /etc/lighttpd/lighttpd.conf pour ajouter les lignes suivantes après la directive ssl.engine = "enable"

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Ensuite, vous devez redémarrer le service lighttpd avec sudo service lighttpd restart et effectuer un test de prise de contact ssl3 comme décrit dans les sections précédentes pour vous assurer que la modification a été correctement mise en œuvre.

Extrait de lien .

Postfix SMTP

Pour «SSL opportuniste» (la politique de chiffrement n’est pas appliquée et la plaine est également acceptable), vous n’avez rien à changer. Même SSLv2 est mieux que simple, donc si vous avez besoin de sécuriser votre serveur, vous devriez quand même utiliser le mode «SSL obligatoire».

Pour le mode "SSL obligatoire" déjà configuré, il suffit d’ajouter / de modifier le paramètre smtpd_tls_mandatory_protocols pour les appels entrants. connexions et smtp_tls_mandatory_protocols pour les connexions sortantes:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Si vous le souhaitez, vous pouvez également désactiver SSLv3 pour le cryptage opportuniste (même si cela n’est pas nécessaire, comme expliqué ci-dessus):

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

et redémarrer Postfix:

sudo service postfix restart

Sendmail

(modification non vérifiée par un utilisateur anonyme, je ne suis pas à l'aise avec Sendmail, veuillez vérifier.)

Ces options sont configurées dans la section LOCAL_CONFIG de votre sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

Dans Dovecot v2.1 +, ajoutez ce qui suit à votre /etc/dovecot/local.conf (ou à un nouveau fichier dans /etc/dovecot/conf.d ):

ssl_protocols = !SSLv2 !SSLv3

et redémarrer Dovecot:

sudo service dovecot restart

Pour les anciennes versions, vous devrez corriger le code source .

Courier-imap (imapd-ssl)

Courier-imap autorise SSLv3 par défaut sur Ubuntu 12.04 et autres. Vous devez le désactiver et utiliser STARTTLS pour forcer TLS. Modifiez votre fichier de configuration /etc/courier/imapd-ssl pour refléter les modifications suivantes

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Serveur HAProxy

SSL est pris en charge dans HAProxy & gt; = 1.5.

Modifiez le fichier /etc/haproxy.cfg et recherchez votre ligne bind . Ajoutez no-sslv3 . Par exemple:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Référence: Documentation HAProxy

OpenVPN

N'apparaît pas affecté ( source ).

  

OpenVPN utilise TLSv1.0 ou (avec & gt; = 2.3.3) en option TLSv1.2 et n’est donc pas affecté par POODLE.

Marionnette

Puppet utilise SSL sur HTTPS mais il n’est pas utilisé par les clients "browser", mais uniquement par les agents Puppet qui ne sont pas vulnérables au vecteur d’attaque indiqué.Cependant, il est préférable de simplement désactiver SSLv3.

Ma recommandation est d'utiliser le module de marionnettes stephenrjohnson / puppetmodule pour configurer votre maître de marionnettes dans lequel J'ai tué SSLv3 il y a quelque temps.

    
réponse donnée gertvdijk 15.10.2014 - 01:49
la source
4

Peut ne pas être spécifique à Ubuntu, mais pour contourner la vulnérabilité de Poodle dans Node.js, vous pouvez définir secureOptions sur require('constants').SSL_OP_NO_SSLv3 lorsque vous créez un serveur https ou tls.

Voir lien pour plus d’informations

    
réponse donnée 3rdEden 15.10.2014 - 10:59
la source
0

Le "correctif" pour messagerie désactive tls 1.1 et tls 1.2. Il ne semble pas y avoir de moyen de gérer le courrier avec tls 1.1 ou plus. Une analyse PCI sur votre serveur peut revenir avec la recommandation suivante:

Configurez les serveurs SSL / TLS pour n’utiliser que TLS 1.1 ou TLS 1.2 s’ils sont pris en charge. Configurez les serveurs SSL / TLS pour qu'ils ne prennent en charge que les suites de chiffrement qui n'utilisent pas de chiffrement par bloc.

    
réponse donnée PrgWiz 27.02.2015 - 15:45
la source
-1

Comme la vulnérabilité POODLE est une faille de conception dans le protocole lui-même et non un bogue d’implémentation, il n’y aura pas de correctifs. Le seul moyen d'atténuer cela est de désactiver SSLv3 sur le serveur Apache. Ajoutez les lignes ci-dessous dans ssl.conf et faites un redémarrage gracieux apache.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
réponse donnée Lal Krishna 16.10.2014 - 00:55
la source

Lire d'autres questions sur les étiquettes