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


Après le Attaque BEAST et Bug Heartbleed, maintenant j'ai entendu parler d'une nouvelle vulnérabilité dans SSL / TLS appelée CANICHE. 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.?

S'il vous plaît, montrez-moi des exemples sur la façon d'éviter cette vulnérabilité.


158
2017-10-14 23:49


origine


Plus d'informations peuvent être trouvées ici Vulnérabilité SSL3 "Poodle" - Braiam
@Braiam Ouais je sais encore, le brillant Thomas! Cependant, c'est une Q & A très orientée cryptographie. Cette Q & R sur AU est censée fournir des informations pratiques et orientées vers Ubuntu. :-) - gertvdijk
Hein? Comment attendez-vous une solution plus pratique que "Si vous n'installez pas les patchs, Níðhöggr dévorera votre rate." - Braiam
@Braiam Tout d'abord: il n'y a pas de patch (lisez ma réponse). Je pense que Thomas fait référence aux appliances plutôt qu’à l’hébergement du serveur web DIY-Ubuntu. Les appliances telles que les équilibreurs de charge proposent généralement des mises à jour du micrologiciel pour modifier les paramètres par défaut ou proposer des fonctionnalités pour pouvoir le configurer. Cependant, dans Ubuntu, tout dépend de l'utilisateur / de l'administrateur. - gertvdijk
En fait, il existe: les fournisseurs peuvent désactiver / supprimer tous les codes liés à SSLv3, vous n'avez donc pas besoin de toucher quoi que ce soit. - Braiam


Réponses:


Informations de fond

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 annoncé que moins de 0,09% de leurs 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.

Donc, encore TOI vous devez 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 dans Ubuntu au niveau de l'implémentation va probablement briser certains éléments pour une utilisation non-HTTPS SSL qui n'est pas tellement vulnérable, donc je suppose que les responsables ne feront pas cela et que seul ce patch SCSV sera appliqué.

Pourquoi la mise à jour SCSV dans 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 pas cela. SCSV garantit uniquement que vous ne passez pas d’un protocole 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 aucun 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 aucune attaque de rétrogradation.

Si vous devez accéder à un serveur qui offre également TLSv1 + et SSLv3 (ce qui est déconseillé) et que vous souhaitez vous assurer que votre connexion ne sera pas rétrogradée vers SSLv3 par un attaquant, alors tous les deux le serveur et le client ont 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 mise à niveau inférieur).

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

En tant qu'utilisateur, vous devez désactiver SSLv3 dans votre navigateur. à présent pour vous protéger lorsque vous visitez des sites Web qui supportent encore SSLv3.

Est-ce que OpenSSL / GnuTLS / browser est 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 un nouveau Libération de sécurité OpenSSL, mais lisez ci-dessous (Mais j'ai vraiment besoin du support SSLv3 ... pour la raison X, Y, Z!) pourquoi 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 de la magie iptables règle 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 exécuté sur la machine de la victime. Ce vecteur ne s'applique pas aux scénarios non HTTPS sans utiliser de navigateur.

De plus, 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ésactiver SSLv3 pour HTTPS à présent, désactivez SSLv3 pour les autres services dans 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. Cette vulnérabilité expose la récupération de texte en clair à partir des données de session, elle ne fournit aucun accès à des secrets (ni la clé de session ni la clé de certificat).

Un attaquant est très probablement seulement capable de voler les en-têtes de texte en clair comme les cookies de session pour effectuer détournement de session. Une contrainte supplémentaire est la nécessité d’un service complet (actif). 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, 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 Guide du serveur TLS de Mozilla. Et test avec Test des laboratoires SSL 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 OpenSSL plus récente de 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 les clients et les serveurs, vous devez simplement passer à TLSv1 +.

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 du protocole. En ai-je besoin?

Seulement si vous avez vraiment besoin de SSLv3 pour une raison quelconque, 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 usn-2385-1. Vous le recevrez via vos mises à jour de sécurité régulières dans votre gestionnaire de paquets.

Test de vulnérabilité pour les sites hébergés en privé (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
    
  • En 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.

  • En utilisant Cipherscan. Cloner / télécharger le binaire et l'exécuter:

    ./cipherscan myhostname.tld
    

    Cela devrait ne pas lister tout avec SSLv3 sous la colonne "Protocoles".


Navigateur Firefox

Ouvrir about:config, trouver security.tls.version.min et définir la valeur à 1. Puis redémarrez votre navigateur pour supprimer les connexions SSL ouvertes.

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


Google Chrome (Linux)

Modifier le /usr/share/applications/google-chrome.desktop fichier, par ex.

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

modifier toutes les lignes 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

Ensuite, assurez-vous 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 cette .desktop fichier lanceur 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 permettra 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 pour votre serveur Web, comme expliqué 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"

Vérifiez ensuite si la nouvelle configuration est correcte (pas de faute 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 en utilisant 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 pour votre serveur Web, comme expliqué 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 public, disponible, testez-le en utilisant Outil SSL Labs de Qualys.


Serveur Web Lighttpd

Les versions Lighttpd> 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 d'Ubuntu supérieures à 12.04.

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

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

Modifier votre /etc/lighttpd/lighttpd.conf ajouter les lignes suivantes après le ssl.engine = "enable" directif

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

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

Pris à partir de http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


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 devez sécuriser votre serveur, vous devriez utiliser le mode «SSL obligatoire» de toute façon.

Pour le mode 'SSL obligatoire' configuré, ajoutez / modifiez simplement le smtpd_tls_mandatory_protocols réglage 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 le souhaitez, désactivez également SSLv3 pour le chiffrement 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é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 le LOCAL_CONFIG section 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émarrer Dovecot:

sudo service dovecot restart

Pour les anciennes versions, vous devrez patcher 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. Modifier votre /etc/courier/imapd-ssl fichier de configuration 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.

Modifier le /etc/haproxy.cfg classer et trouver votre bind ligne. Ajouter no-sslv3. Par exemple:

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

Référence: Documentation HAProxy


OpenVPN

Semble ne pas être affecté (la source).

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


Fantoche

Puppet utilise le protocole SSL sur HTTPS, mais il n'est pas utilisé par les clients "navigateur", mais uniquement par les agents Puppet qui ne sont pas vulnérables au vecteur d'attaque affiché. Cependant, il est recommandé de simplement désactiver SSLv3.

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


210
2017-10-14 23:49



Cette réponse a été créée très rapidement après la publication de la vulnérabilité. Il y a peut-être encore des erreurs - comme toujours, n'hésitez pas à modifier / améliorer. - gertvdijk
Nginx config ne devrait pas avoir de deux-points après la directive ssl_protocols - Michelle
Bon, pour Firefox je crois ce est ce qui se passe - fuglede
Ce billet de blog de Mozilla Security suggère d'installer cet add-on au lieu de modifier les préférences manuellement. - legoscia
@muru Voici un début pour tuer SSLv3 au niveau du pare-feu. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Peut-être ne pas être spécifique à Ubuntu mais pour contourner la vulnérabilité de 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
2017-10-15 08:59



IMO vous ne devriez pas exposer HTTP (S) avec Node / Python / Ruby ou quelque chose comme ça directement. Placez un HTTPd décent comme Apache / Nginx / ... - gertvdijk
Oui, vous ne devriez pas exposer directement. Les langages ne sont pas très bons avec la couche HTTP TCP, mais ils jouent un rôle important dans les sockets. Laissez nginx le lire depuis un socket. :-) - jrg♦
Cela ne méritait pas un vote bas. Il y a beaucoup de cas où tls est utilisé en plus de l'hébergement d'un serveur http. - psanford
@gertvdijk & jrg Node.js n'est pas une langue. C'est un cadre pour la création d'applications réseau évolutives. Et comme vous déclarez que vous devriez placer Node.js derrière un serveur Apache (et même l'appeler "décent"), il est déjà clair que vous n'avez absolument aucune idée de ce dont vous parlez. Indiquer qu'ils ne sont pas bons avec tpc / http est évidemment un parti pris personnel. S'il vous plait, restez sur le sujet, au lieu d'une technologie de vote enfantin que vous ne comprenez pas. - 3rdEden
@ 3rdEden Eh bien, ma remarque était peut-être un peu généralisante, mais voici quelques notes que j'aimerais faire. 1) Je n'ai pas vaincu, 2) mon commentaire était un «IMO», 3) Peut-être que ce n'est que mon expérience en sécurité, mais j'ai appris qu'il ne fallait pas exposer un cadre d'application directement au 80/443 production. (sauf à des fins de démonstration). 4) Je ne vois pas comment votre message est une «réponse» à la question pour le visiteur général Ask Ubuntu; c'est très très spécifique à un cas spécifique des déploiements de Node.js. - gertvdijk


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 qu'ils utilisent uniquement 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 n'utilisant pas de chiffrement par bloc.


0
2018-02-27 14:45





Comme la vulnérabilité POODLE est un défaut 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 effectuez un redémarrage rapide d'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"

-1
2017-10-15 22:55



-1 pour inclure RC4 et ECDSA non fonctionnel car la plupart des gens ont des certificats RSA. Lisez simplement comment configurer votre serveur correctement. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Je suis d'accord avec vous à propos de RC4, mais cela ne fait pas de mal d'inclure les suites ECDSA. C'est inoffensif si vous ne disposez que d'un certificat RSA et vous évite de réparer votre configuration si vous obtenez ultérieurement un certificat ECDSA. - Matt Nordhoff
@MattNordhoff Assez, mais ce que je veux dire, c’est qu’il ne reste plus beaucoup de chiffrements pour une configuration basée sur des certificats RSA. Cela fonctionnera dans la plupart des navigateurs, mais des problèmes de compatibilité peuvent survenir. - gertvdijk
Débarrassez-vous de RC4 de cette liste, ce n'est pas sûr. Restez avec le reste si vous le pouvez. 3DES est faible, mais je l'ai fait dans un endroit particulier pour la compatibilité. Je déteste le faire car il est faible, mais au moins ce n'est pas vraiment cassé ... - Brian Knoblauch