web-dev-qa-db-fra.com

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

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

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

S'il vous plaît me montrer des exemples sur la façon d'éviter cette vulnérabilité.

securityssltls
158
gertvdijk

Informations de fond

SSL est conçu pour sécuriser le niveau de transport sur Internet. Pour "le Web", c'est-à-dire HTTP, vous le reconnaîtrez sous le nom de HTTPS, mais il est également utilisé pour d'autres protocoles d'application. SSLv2 était le premier protocole de sécurité de transport largement utilisé, mais a été découvert peu sûr peu de temps après. Les successeurs SSLv3 et TLSv1 sont maintenant largement pris en charge. TLSv1.1 et TLSv1.2 sont plus récents et gagnent également en support. La plupart des navigateurs Web publiés à partir de 2014, sinon tous, sont compatibles.

La récente découverte par les ingénieurs de Google indique que SSLv3 ne doit plus être utilisé (car SSLv2 est obsolète depuis longtemps). Les clients qui ne pourront pas se connecter à votre site/service sont probablement très très limités. CloudFlare annoncé que moins de 0,09% de leurs visiteurs utilisent encore SSLv3.

Solution simple: désactivez SSLv3.

Ubuntu fournit-il des mises à jour?

Oui, via sn-2385-1 avec l’ajout de la fonctionnalité SCSV, , mais cela n’atténue pas complètement le problème , car cela 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.

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

Désactiver complètement SSLv3 par défaut dans Ubuntu au niveau de l’implémentation risque d’éclater certaines choses également pour une utilisation SSL non-HTTPS qui n’est pas si vulnérable. Je suppose donc que les responsables ne le feront pas et que ce correctif SCSV sera appliqué.

Pourquoi la mise à jour SCSV dans OpenSSL via usn-2385-1 ne permet-elle pas de résoudre le problème?

Vraiment, arrêtez de poser de telles questions et sautez quelques paragraphes et désactivez SSLv3. Mais bon, si vous n'êtes pas convaincu, c'est parti:

POODLE montre que SSLv3 avec les chiffrements CBC est cassé, implémenter SCSV ne change rien à cela. SCSV s'assure uniquement que vous ne rétrogradez pas un protocole TLS vers un protocole TLS/SSL inférieur, au besoin, avec l'attaque Man-in-the-Middle requise dans les cas habituels.

Si vous devez accéder à un serveur qui n'offre pas du tout TLS, mais uniquement SSLv3, votre navigateur n'a pas vraiment le choix et doit parler au serveur à l'aide de SSLv3, qui est alors vulnérable sans aucune attaque par rétrogradation.

Si vous devez accéder à un serveur proposant également TLSv1 + et SSLv3 (ce qui est déconseillé) et que vous voulez être sûr que votre connexion ne sera pas dégradée en SSLv3 par un attaquant, alors le serveur et le client ont besoin de ce correctif SCSV.

Pour atténuer complètement le problème, la désactivation de SSLv3 est suffisante et vous pouvez être sûr de ne pas être rétrogradé. Et vous ne pourrez pas parler aux serveurs uniquement SSLv3.

Bon, alors 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.

Est-ce que seuls les serveurs ou aussi les clients sont affectés?

La vulnérabilité existe si le serveur et le client acceptent tous deux SSLv3 (même s'ils sont tous deux capables de TLSv1/TLSv1.1/TLS1.2 en raison d'une attaque par déclassement).

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

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

Est-ce spécifique à OpenSSL/GnuTLS/au navigateur?

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

Et oui, il y a un nouveau version de sécurité OpenSSL , mais lisez ci-dessous ( mais j'ai vraiment besoin du support de SSLv3 ... pour la raison X, Y, Z! ) sur la raison pour laquelle vous feriez mieux de vous concentrer sur la désactivation de SSLv3.

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

Oui, probablement. Je mets cela dans un article de blog séparé pour plus de réflexion et de travail. Nous pouvons avoir une règle magique iptablesque vous pouvez utiliser!

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

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

Les chercheurs ont montré que le vecteur d’attaque actuel contrôlait le texte en clair envoyé au serveur à l’aide de Javascript qui était exécuté sur la machine de la victime. Ce vecteur ne s'applique pas aux scénarios non-HTTPS sans l'utilisation d'un navigateur.

De plus, normalement, un client SSL ne permet pas de rétrograder la session en SSLv3 (TLSv1 + étant vu dans les capacités de négociation), mais les navigateurs veulent être très compatibles avec les versions antérieures et ils 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 rend exploitable.

Conclusion: désactivez SSLv3 pour HTTPS maintenant , désactivez SSLv3 pour les autres services dans la fenêtre de service suivante.

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 en texte clair, tels que les cookies de session, afin d'effectuer détournement de session . Une contrainte supplémentaire est la nécessité d'une attaque (active) attaque MitM .

Y a-t-il autre chose que je puisse faire pour améliorer ma configuration SSL en général?

En tant qu'utilisateur, outre la désactivation de SSLv3 dans votre navigateur, pas vraiment. Eh bien, installez toujours les dernières mises à jour de sécurité.

Pour les serveurs, suivez Guide du serveur TLS de Mozilla . Et testez avec test de Qualys 'SSL Labs . Ce n'est vraiment pas difficile d'obtenir une cote A + sur votre site. Il suffit de mettre à jour vos paquets et de mettre en œuvre 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 évite l'attaque par rétrogradation des clients compatibles TLSv1, appelé Protection de remplacement SSLv3. Soit dit en passant, cela améliorera également la sécurité de TLSv1 + (une attaque par déclassement est plus difficile/impossible). Il est proposé comme portage d'une version OpenSSL plus récente dans l'avis de sécurité Ubuntu sn-2385-1 .

Gros problème: les clients et les serveurs ont besoin de ce correctif pour fonctionner. Donc, à mon avis, pendant la mise à jour des clients et des serveurs, vous devriez quand même passer à TLSv1 +.

Cependant, s'il vous plaît, retirez simplement SSLv3 de votre réseau pour l'instant. Faites des efforts pour mettre à niveau les normes de sécurité et abandonnez simplement SSLv3.

J'ai entendu parler du support SCSV pour éliminer l'attaque par rétrogradation de protocole. Est-ce que j'en ai besoin?

Seulement si vous avez vraiment besoin de SSLv3 pour une raison étrange, mais que 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 sn-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é. Si cela échoue, il est désactivé. Quand cela échoue, vous devriez voir quelque chose comme:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

  • Utilisation de nmapname__:

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

    Il devrait générer '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 devrait ne pas répertorier quoi que ce soit avec SSLv3 dans la colonne "protocoles".

Navigateur Firefox

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

Firefox à partir de la version 34 désactivera SSLv3 par défaut et ne nécessitera donc aucune action ( source ). Cependant, au moment de la rédaction de cet article, 33 articles sont tout juste publiés et 34 sont prévus pour le 25 novembre.

Google Chrome (Linux)

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

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

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

Par exemple. 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 permettent peut-être de garder votre navigateur actif en arrière-plan!).

Remarque: vous devrez peut-être répéter cette opération à chaque mise à jour du paquet google-chrome, en écrasant ce fichier de lancement .desktop. Un navigateur Google Chrome ou Chromium avec SSLv3 désactivé par défaut n'est pas encore annoncé au moment de la rédaction.

Apache HTTPD Server

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 voudrez peut-être envisager d’améliorer la configuration de ciphersuite pour votre serveur Web, comme expliqué à la section Guide du serveur TLS de Mozilla . 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"

Puis vérifiez 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'infos: documentation Apache

Maintenant, testez-le: si votre site est publiquement disponible, testez-le avec outil Qualys ’SSL Labs .

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 voudrez peut-être envisager d’améliorer la configuration de ciphersuite pour votre serveur Web, comme expliqué à la section Guide du serveur TLS de Mozilla . 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 avec outil SSL Labs de Qualys .

Serveur web Lighttpd

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

Pour Ubuntu version 12.04 ou Debian 6, un paquet lighttpd mis à jour est disponible à partir du référentiel openSUSE: http://download.opensuse.org/repositories/server:/http/Debian_6.

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

Editez 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 un 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é implémentée avec succès.

Tiré de http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .

Postfix SMTP

Pour le "SSL opportuniste" (la politique de chiffrement n'est pas appliquée et le langage clair est également acceptable), vous n'avez rien à changer. Même si SSLv2 est meilleur que tout simplement, si vous avez besoin de sécuriser votre serveur, vous devriez quand même utiliser le mode "SSL obligatoire".

Pour que le mode 'SSL obligatoire' soit déjà configuré, ajoutez/modifiez simplement le paramètre smtpd_tls_mandatory_protocols pour les connexions entrantes et smtp_tls_mandatory_protocols pour les connexions sortantes:

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

Si vous souhaitez également désactiver SSLv3 pour le chiffrement opportuniste (même s'il est inutile comme expliqué ci-dessus), procédez comme suit:

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

et redémarrez Postfix:

Sudo service postfix restart

Envoyer un mail

(édition 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

Pigeonnier

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émarrez Dovecot:

Sudo service dovecot restart

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

Courrier-imap (imapd-ssl)

Courier-imap autorise SSLv3 par défaut sur Ubuntu 12.04 et autres. Vous devez le désactiver et utiliser STARTTLS à la place pour forcer TLS. Editez 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!>"

HAProxy Server

SSL est pris en charge dans HAProxy> = 1.5.

Editez le fichier /etc/haproxy.cfg et trouvez votre ligne bindname__. Ajoutez no-sslv3. Par exemple:

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

Référence: Documentation HAProxy

OpenVPN

Semble ne pas être affecté ( source ).

OpenVPN utilise TLSv1.0 ou (avec> = 2.3.3) éventuellement TLSv1.2 et n'est donc pas impacté par POODLE.

Fantoche

Puppet utilise SSL sur HTTPS mais il n'est pas utilisé par les clients du "navigateur", mais par les agents de Puppet qui ne sont pas vulnérables au vecteur d'attaque affiché. Cependant, il est préférable de 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é SSLv il y a quelque temps.

210
gertvdijk

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

Voir https://Gist.github.com/3rd-Eden/715522f6950044da45d8 pour plus d'informations.

4
3rdEden

Le "correctif" pour les messageries désactive les niveaux 1.1 et 1.2. Il ne semble pas y avoir de moyen de faire fonctionner un service de messagerie avec une version 1.1 ou supérieure. Un scan PCI sur votre serveur peut revenir avec la recommandation suivante:

Configurez les serveurs SSL/TLS pour qu'ils n'utilisent que TLS 1.1 ou TLS 1.2 s'ils sont pris en charge. Configurez les serveurs SSL/TLS pour ne prendre en charge que les suites de chiffrement n'utilisant pas de chiffrements en bloc.

0
PrgWiz