Poodle: Désactiver SSL V3 sur le serveur est-il vraiment une solution?

J'ai lu toute la journée sur la vulnérabilité de Poodle et je suis un peu confus face à Security and Revenue.

Si je désactive SSL V3 sur le serveur (SSL V2 et V3 seront désactivés pour Apache), les clients (navigateurs) qui ne prennent en charge aucun protocole, mais SSL V3 ne pourront pas connecter HTTPS au serveur.

Il s’agit donc d’une situation où le client et le serveur doivent communiquer avec TLS 1.1 1.2, etc.

Si l'un d'entre eux utilise SSL V3 et que l'autre ne prend pas en charge les versions inférieures, que se passe-t-il? Pas de connexion à SSL.

J'ai vu peu de mises à jour apportées à Firefox. Peut-être ont-ils désactivé SSL V3 en ce sens que nous devons généralement faire dans les options. Cela forcera toute la connexion aux versions inférieures et TLS

Mais la désactivation de SSL V3 est-elle vraiment une solution à ce problème?

D'abord, éclaircissons un peu les choses:

• TLS a remplacé SSL. TLS 1.0 est venu après et est une mise à jour de SSL 3.0.

  TLS 1.2> TLS 1.1> TLS 1.0> SSL 3.0> SSL 2.0> SSL 1.0

• Les versions SSL antérieures à la version 3.0 connaissaient depuis longtemps des vulnérabilités de sécurité graves et sont désactivées / non prises en charge par les clients et les serveurs modernes. SSL 3.0 sera probablement le même bientôt.

• Parmi les protocoles actuellement utilisés, "Poodle" affecte le plus sérieusement SSL 3.0, où il n'y a aucun moyen de l'atténuer. Il y a une attaque similaire contre certains TLS 1.0 et 1.1 implémentations que la spécification permet - assurez - vous que votre logiciel est à jour.

Désormais, la raison pour laquelle "Poodle" représente un risque, même avec les clients et les serveurs modernes, est due à la mise en œuvre par les clients d'un mécanisme de repli. Tous les serveurs ne prendront pas en charge les dernières versions. Les clients essaieront chaque version dans l'ordre, de la plus récente à la plus récente (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0) jusqu'à ce qu'elle trouve celle que le serveur prend en charge. Cela se produit avant le début de la communication chiffrée. Ainsi, un attaquant de l'homme du milieu (MITM) est capable de forcer le navigateur à utiliser une version plus ancienne, même si le serveur en prend en charge une plus récente. C'est ce que l'on appelle une attaque par dégradation de protocole.

Plus précisément, dans le cas de "Poodle", tant que le client et le serveur prennent en charge SSL 3.0, un attaquant de MITM est capable de forcer l'utilisation de ce protocole.

Ainsi, lorsque vous désactivez SSL 3.0, cela a deux effets:

• Les clients qui prennent en charge les versions supérieures ne peuvent pas revenir à la version vulnérable ( TLS Fallback SCSV est un nouveau mécanisme proposé pour empêcher une attaque par déclassement de protocole, mais tous les clients et serveurs ne le prennent pas encore en charge). C'est la raison pour laquelle vous souhaitez désactiver SSL 3.0. La grande majorité de vos clients appartiennent probablement à cette catégorie, ce qui est bénéfique.

• Les clients qui ne supportent pas du tout TLS (comme d'autres l'ont déjà mentionné, IE6 sur XP est à peu près le seul encore utilisé pour HTTPS) ne pourra pas se connecter via une connexion chiffrée. Il s’agit probablement d’une portion mineure de votre base d’utilisateurs, et il ne vaut pas la peine de sacrifier la sécurité de la majorité des personnes mises à jour pour répondre aux besoins de cette minorité.

Votre évaluation est correcte. Les clients devront utiliser des protocoles plus récents pour se connecter à votre serveur une fois que vous aurez désactivé SSL 3. Le protocole SSL 3 est défectueux et il n'y aura pas de "correctif". Désactiver SSL 3 est la seule solution.

À ce stade, de nombreux sites ont désactivé SSL 3, ce qui rend pratiquement inévitable la mise à niveau des utilisateurs de navigateurs plus anciens. En supposant que vous vous connectiez à des chaînes d’agent d’utilisateur, vous pouvez consulter vos journaux et prendre une décision éclairée concernant la désactivation de SSL 3. Il est probable que seul un faible pourcentage des visiteurs de votre site utilise des navigateurs qui ne pourraient pas gérer les protocoles plus récents.

[fwiw - cloudflare rapporte 1,12% d'utilisateurs IE6 XP selon SSLv3]

Oui, la désactivation de SSL3 fera en sorte que les utilisateurs qui ne prennent pas en charge TLS ne puissent pas accéder à votre site Web.

Cependant, d'un point de vue pratique, regardez quels navigateurs entrent dans cette catégorie. Chrome et Firefox prennent tous deux en charge TLS et vont même abandonner complètement la prise en charge de SSL3 en raison de ce bogue. IE le supporte depuis IE7. Le seul navigateur qui ne prend pas en charge, mais qui est toujours utilisé à l'échelle mondiale, est IE6, et la seule raison qui l'utilise encore est deux raisons:

1. N'importe qui avec une version fissurée de XP et aucun moyen d'utiliser Chrome ou Firefox;
2. N'importe qui sur une politique d'entreprise ou gouvernementale avec des restrictions concernant le choix du navigateur.

Dans les deux cas, IE6 est utilisé car il s'agit du navigateur Windows XP par défaut fourni avec l'installation d'origine. En outre, la seule raison pour laquelle IE6 détient toujours une (petite) part du marché mondial est due aux nombreux utilisateurs en Chine.

Donc, longue histoire: voici 3 questions:

1. Avez-vous une base d'utilisateurs chinoise significative?
2. Votre site Web fournit-il une assistance pour IE6, même s'il est obsolète et endommagé?
3. Votre site Web est-il un produit utilisé par un gouvernement ou une société avec des restrictions de choix de navigateur?

Si l'un de ces 3 est vrai, vous devrez trouver une autre solution. Si tous les 3 sont faux, désactivez-le et finissez-en. Et si vous avez besoin d’une autre solution, ne tentez-vous pas de convaincre cette petite partie de votre base d’utilisateurs qui utilise encore IE6 de s’éloigner d’un navigateur vieux de 13 ans?

Vous mentionnez " Apache " et " navigateurs " dans votre question, mais le titre est plus général.

Comme le soulignent Evan et d’autres, le problème est presque résolu pour HTTPS. Cependant, un serveur peut chiffrer un certain nombre d'autres protocoles, et la prise en charge de TLS est bien plus médiocre parmi cette base de clients (comme je l'ai découvert ce matin, lorsque le paramètre "no SSL3" n'est pas obligatoire sur un serveur IMAP / S).

Je crains donc que la réponse soit " cela dépend des services que vous chiffrez et du support client pour TLS parmi votre base d'utilisateurs ".

Edit : oui, c'était ce que je voulais dire, même si je suis heureux que vous soyez d'accord. La désactivation de sslv3 est effectuée service par service. Par exemple, pour éteindre le pigeonnier, il faut mettre

ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

dans dovecot.conf. Le plus gros problème est que, alors que la plupart des navigateurs sont tolérants à la perte de SSLV3, les clients des autres services semblent beaucoup moins tolérants. J'ai cassé environ la moitié de mes utilisateurs ce matin en désactivant le pigeonnier; Les téléphones Android qui exécutent le courrier K-9 et Outlook sur Win7 sont deux choses que je sais avec certitude, mais je peux voir dans mes journaux qu'il y en avait plus.

Désactiver SSLv3 n’est pas seulement une solution valable, c’est la seule solution; mais ça va faire mal.

Edit 2 : merci à dave_thompson_085 pour avoir signalé que la désactivation des chiffrements SSLv3 dans le pigeonnier désactive non seulement le protocole SSLv3, mais également les protocoles TLSv1.0 et TLSv1.1, car ils ne disposent pas de chiffrements similaires à ceux du protocole précédent. Dovecot (du moins les versions antérieures, y compris celle que j'utilise) ne semble pas avoir la capacité de configurer des protocoles plutôt que des suites de chiffrement. Cela explique probablement pourquoi cela a brisé tant de clients.

Désactiver SSLv3 est la meilleure solution, mais je ne pense pas que ce soit la seule solution. Comme le décrit CloudFlare, l'utilisation de SSLv3 est très faible , la plupart des administrateurs ne devraient donc avoir aucun problème à l'éteindre.

Si vous avez des exigences particulières pour SSLv3, vous devez peut-être prendre en charge IE6 sous Windows XP ou des logiciels très anciens, il existe un autre moyen de les atténuer.

La manière de le limiter et de conserver SSLv3 consiste à utiliser RC4 et à prendre en charge TLS Fallback SCSV, fourni par OpenSSL 1.0.1j. Dans le post de qualys sur caniche , RC4 est le "chiffrement de flux non sécurisé dont personne ne veut mentionner le nom".

C’est ce que Google fait sur mail.google.com, et ils le décrivent également dans leur entrée de blog: http://googleonlinesecurity.blogspot.se/2014/10/this-poodle-bites-exploiting-ssl-30.html

Il manque un détail dans la conversation. D'après la question initiale, il peut être judicieux de le noter. TLS 1.0 est aussi appelé SSL 3.1, donc affiche originale, vous devriez regarder votre configuration, utilisez-vous v3.0 ou v3.1

Comme dans la plupart des cas, la réponse est "cela dépend". IE6 est le seul navigateur faisant l'objet d'une utilisation "commune" qui ne prend pas en charge TLS. Malheureusement, selon divers rapports, IE6 pourrait représenter jusqu'à quelques pour cent des demandes HTTP mondiales (voir: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html ). . La bonne nouvelle, si vous vivez en Amérique du Nord, c'est qu'il est relativement rare aux États-Unis. Pour plus de sécurité, vous devriez consulter les statistiques sur les agents utilisateurs à partir de vos journaux www. Dans mon cas, il y avait si peu d'empreintes digitales IE6 ua que je pensais qu'elles provenaient toutes d'outils de test.

Vous pouvez tester votre / vos site (s) Web avec le testeur de ssllab pour voir comment divers agents réagissent.

https://www.ssllabs.com/ssltest/

TL; DR - SSLv3 est mort; vive TLS.