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


39

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?


4
Qu'entendez-vous par "Cela forcera toutes les connexions vers les versions inférieures et TLS"? SSLv1 et SSLv2 sont désactivés depuis longtemps car ils ont été cassés. SSLv3 a été mal vu, mais dans de nombreux cas, il restait activé pour prendre en charge les logiciels hérités. Quelle est la version inférieure à laquelle vous vous référez? TLSv1.0, v1.1, v1.2, ... sont des normes plus récentes et peuvent être considérées comme "SSL de version supérieure", seuls les numéros de version ont été réinitialisés avec le changement de nom.
Håkan Lindqvist

Bonjour, c’est ce que j’ai compris jusqu’à présent. Si je désactive également SSL V3 et V2 sur le serveur, comme le recommande Red Hat, la connexion sécurisée se fera sur le protocole TLS. Et si les navigateurs passent un appel sur TLS avec le serveur, les connexions sécurisées ne poseront aucun problème. Je ne dispose pas des informations exactes sur les différences entre les versions b / w SSL et TLS.
sandeep.s85

Réponses:


52

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é.


8
Bonjour Bob, c'est Alice ici. Tout comme votre explication sur la façon dont Mallet peut utiliser Poodle.
BatteryBackupUnit

+1 Ne connaissait pas l'attaque par rétrogradation de protocole.
developerwjk

1
MISE À JOUR: "...everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken, including many implementations which conform to current specifications." zdnet.com/article/poodle-not-fixed-some-tls-systems-vulnerable
BlueCacti

@GroundZero > Mais il s'est avéré que certaines implémentations TLS ne vérifiaient toujours pas les octets de remplissage, malgré leur capacité à le faire. => Plus précisément, alors que TLS 1.0 et 1.1 implémentations peuvent être cassés (et la spécification permet qu'ils soient cassés de cette façon, ce qui est bon), ce n'est pas aussi mauvais que SSL 3.0 où la spécification elle - même était cassé et il n'y avait pas moyen pour une implémentation conforme de contourner le problème. En outre, "désactiver" la prise en charge de TLS 1.0 et 1.1 sur le serveur est un problème beaucoup plus difficile que de désactiver SSL 3.0 - vous affecterez une proportion beaucoup plus grande d'utilisateurs.
Bob

On dirait que ce sont principalement les implémentations côté serveur qui sont vulnérables (?) - corrigez votre implémentation TLS sur le serveur, et tout devrait bien aller (?) [Je n'ai pas suffisamment examiné la question pour confirmer que les navigateurs et les autres clients ne sont pas affectés. , mais le libellé de votre article lié et de sa source suggère que].
Bob

27

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]


1
Il est vrai que SSLv3 est erronée, et la seule vraie solution est de désactiver SSLv3. Si vous acceptez le chiffrement RC4 pour les clients TLS 1.0, il existe également une mesure d'atténuation pour l'attaque du caniche, qui ne nécessite pas la désactivation de SSLv3, car le caniche n'affecte que les chiffrements en mode CBC (AES). Je l' ai décrit ici: serverfault.com/q/637848/249649
CYPRES

2
TLS_FALLBACK_SCSVn'atténue pas l'attaque pour les clients plus âgés, cependant. Cela permet simplement aux anciens clients de continuer à utiliser le protocole défectueux tout en évitant les rétrogradations indésirables des versions de protocole pour les nouveaux clients. En fin de compte, laisser SSLv3 activé pour tous les clients expose potentiellement leur trafic à des attaquants.
Evan Anderson

RC4 atténue cette attaque pour les clients plus âgés, pas scsv. Mais nous préférons ne pas utiliser RC4, raison pour laquelle je recommande également de désactiver SSLv3 si possible.
Cypres

1
@cypres - Yes-- 'TLS_FALLBACK_SCSV' n'aide pas les clients plus anciens. Je dirais que l'utilisation d'un chiffre qui a montré de graves faiblesses n'est pas utile non plus. Nous devons laisser cela être un "jour du drapeau" qui élimine SSL 3.0 du réseau. Bien sûr - si vous avez d'anciennes appliances, des périphériques intégrés, etc., qui ne prennent pas en charge TLS dans votre entreprise, n'hésitez pas à exécuter SSL 3.0. Je pense cependant qu'il est irresponsable d'encourager quiconque à continuer à utiliser SSL 3.0 sur l'Internet public.
Evan Anderson

Aujourd'hui, j'ai désactivé SSLv3 sur Firefox pour n'autoriser que TLS et je vois assez de problèmes de connexion SSL lors de la navigation sur des sites Web sur Internet. Je prends en charge des centaines de serveurs Linux sur lesquels sslv3 est activé. Je me trompe peut-être, mais la solution ultime à cette situation est que les fournisseurs de systèmes d'exploitation publient un correctif, de sorte que rien ne soit fait côté client. Le problème est que vous ne pouvez pas prédire l’impact.
sandeep.s85

20

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?


7

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.


1
Je viens également de lire que cela affectera non seulement les serveurs Web, mais également tout service fonctionnant sur le serveur qui utilise SSL, c’est-à-dire les serveurs Web, les serveurs LDAP, les démons SSH, les serveurs POP3, les serveurs SMTP. Nous avons donc une configuration dans Apache Fichier de configuration mod_ssl en tant que SSLProtocol Tous -SSLv2 -SSLv3 Nous devons également examiner d'autres services afin d'empêcher client / serveur d'utiliser SSLv3
sandeep.s85

L’attaque POODLE proprement dite, telle que décrite dans l’avis de sécurité , repose sur un grand nombre de demandes émises avec une certaine capacité de contrôle de la part de l’attaquant. Dans le contexte de HTTPS et des navigateurs, cela est réalisable grâce au script mais dans le contexte, par exemple, d'IMAPS, je ne suis pas convaincu qu'il s'agisse d'une chose pratique à faire. Il est bien sûr idéal de se débarrasser de SSLv3, mais je ne suis pas sûr que POODLE en particulier soit tout à fait pertinent pour certains de ces autres cas.
Håkan Lindqvist

Håkan, avec le temps, je suis de plus en plus en accord avec vous.
MadHatter soutient Monica

3
Désactiver les algorithmes !SSLv3 de chiffrement dans openssl désactive en réalité tous les protocoles à l'exception de TLSv1.2, ce qui pourrait ne pas être avantageux pour vos pairs. C’est pourquoi il est préférable de désactiver le protocole , mais AFAICS ne figure que dans le pigeonnier 2.1+. Voir security.stackexchange.com/questions/71872/… .
dave_thompson_085

@ dave_thompson_085: quand vous dites " désactivation ... dans openssl ", voulez-vous dire " désactivation ... dans le pigeonnier "? Si tel est le cas, je suis d’accord avec vous et je modifierai ma réponse à la lumière de ces informations, si vous pouviez apporter les éclaircissements demandés.
MadHatter soutient Monica

6

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


2
Je ne sais vraiment pas ce qui est pire, laisser le système ouvert à Poodle ou rétrograder au RC4 ...
Brian Knoblauch

Les clients qui prennent en charge TLS 1.1+ ne passent pas à la version RC4. Je ne suis pas un expert, mais je crois que le caniche est pire.
Cypres

RC4 ne représente-t-il pas essentiellement Raw Cleartext?
Hagen von Eitzen

1
Vous plaisantez sûrement, mais soulevez un point valable. Ce n'est pas si mal, c'est une très bonne réponse à ce problème de sécurité: security.stackexchange.com/a/32498
cypres

2

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


-3

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.


15
IE6 n'est pas la dernière version compatible avec XP, c'est la version livrée avec XP. IE8 est la dernière version compatible avec XP.
Håkan Lindqvist

6
-1 en raison d'une inexactitude factuelle indiquant qu'IE6 est la dernière version disponible sur xp.
TomTom

may be as much as a few percent of global HTTP requests. Je voudrais une source pour cela. CloudFlare dit ceci à propos de l'utilisation: In other words, even on an out-of-date operating system, 98.88% Windows XP users connected using TLSv1.0+( blog.cloudflare.com/… ). Ce qui est beaucoup moins que "quelques pour cent" dans le monde.
Faker

1
Je soupçonne que les clients de cloudflares sont principalement de grandes entreprises nord-américaines. La statistique que j'ai citée vient de netcraft: news.netcraft.com/archives/2014/10/15/… "Malgré son âge et la fin du support de Microsoft pour Windows XP, IE6 reste populaire, représentant plus de 3,8% des visites Web dans le monde. et 12,5% en Chine. Cette vulnérabilité pourrait sonner le glas de IE6 et Windows XP. "
Joshua Hoblitt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.