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 en tant que 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 a annoncé que moins de 0,09% de ses visiteurs utilisent encore SSLv3.
Solution simple: désactivez 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.
Donc, vous devez toujours 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 seul 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 qui offre TLSv1 + et SSLv3 trop ( ce qui est déconseillé) et que vous voulez être sûr que votre connexion ne sera pas rétrogradé à SSLv3 par un attaquant, alors à la fois le serveur et le client besoin de ce patch SCSV.
Pour atténuer complètement le problème, la désactivation de SSLv3 vous suffit et vous pouvez être sûr de ne pas être rétrogradé. Et vous ne pourrez pas communiquer avec des serveurs exclusivement 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 maintenant désactiver SSLv3 dans votre navigateur 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 une nouvelle 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 iptablesrègle magique que vous pouvez utiliser!
Mon article de blog: Comment éliminer SSLv3 de 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?
Comme l'indiquent les chercheurs, le vecteur d'attaque actuel fonctionne avec le contrôle du texte en clair envoyé au serveur à l'aide de Javascript qui est 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 prise de contact), mais les navigateurs veulent être très compatibles avec les versions antérieures. 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 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 en texte clair, tels que les cookies de session, afin de réaliser un détournement de session . Une contrainte supplémentaire est la nécessité d'une attaque MitM complète (active) .
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 le guide du serveur TLS de Mozilla . Et testez avec le test 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 contourne 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 n ° 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 aussi 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é. 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
Utilisant 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 chiffrements . Clonez / téléchargez le binaire et exécutez-le:
./cipherscan myhostname.tld
SSLv3 ne doit pas être répertorié dans la colonne "protocoles".
Navigateur Firefox
Ouvrez about:config, recherchez security.tls.version.minet 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 /usr/share/applications/google-chrome.desktopfichier, par exemple
sudo nano /usr/share/applications/google-chrome.desktop
Éditez toutes les lignes en commençant par Exec=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 .desktopfichier de lancement. 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é dans le 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"
Ensuite, 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 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 voudrez peut-être envisager d’améliorer la configuration de ciphersuite pour votre serveur Web, comme expliqué dans le 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 à l'aide de l'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 à la 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 qu’un correctif simple n’est donc pas disponible pour ces distributions. Par conséquent, ce correctif ne doit ê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.0
Le paquet est destiné à Debian 6 (squeeze) mais fonctionne également à 12.04 (précis)
Modifiez votre /etc/lighttpd/lighttpd.confpour ajouter les lignes suivantes après la ssl.engine = "enable"directive
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
Ensuite, vous devez redémarrer le service lighttpd avec a sudo service lighttpd restartet effectuer un test de prise de contact SSL 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 tout est acceptable), vous n'avez rien à changer. Même si SSLv2 est meilleur que tout à fait, alors si vous devez 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
(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 LOCAL_CONFIGsection de votresendmail.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 patcher 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 /etc/courier/imapd-sslfichier de configuration pour refléter les changements suivants
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 /etc/haproxy.cfgfichier et trouvez votre bindligne. Append 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é SSLv3 il y a quelque temps.