Comment réparer la vulnérabilité 'logjam' dans Apache (httpd)


56

Récemment, une nouvelle vulnérabilité dans Diffie-Hellman, dénommée de manière informelle «impasse», a été publiée. Cette page a été préparée et suggère comment remédier à cette vulnérabilité:

Nous avons trois recommandations pour déployer correctement Diffie-Hellman pour TLS:

  1. Désactiver les suites de chiffrement d'exportation. Bien que les navigateurs modernes ne prennent plus en charge les suites d’exportation, les attaques FREAK et Logjam permettent à un attaquant intransigeant de tromper les navigateurs en leur demandant d’utiliser une cryptographie de niveau export, après quoi la connexion TLS peut être déchiffrée. Les codes d'exportation sont un vestige de la politique des années 1990 qui empêchait l'exportation de protocoles cryptographiques puissants à partir des États-Unis. Aucun client moderne ne s'appuie sur les suites d'exportation et il y a peu d'inconvénients à les désactiver.
  2. Déployer (éphémère) Elliptic-Curve Diffie-Hellman (ECDHE). L'échange de clé Elliptic-Curve Diffie-Hellman (ECDH) évite toutes les attaques cryptanalytiques possibles et connues, et les navigateurs Web modernes préfèrent désormais ECDHE à celui de Diffie-Hellman, le champ fini. Les algorithmes de log discrets utilisés pour attaquer les groupes Diffie-Hellman standard ne tirent pas un avantage aussi important du précalcul et les serveurs individuels ne doivent pas générer de courbes elliptiques uniques.
  3. Générez un groupe Diffie Hellman puissant et unique . Des millions de serveurs utilisent quelques groupes fixes, ce qui en fait une cible optimale pour le précalcul et les écoutes éventuelles. Les administrateurs doivent générer des groupes Diffie-Hellman uniques, 2048 bits ou plus, en utilisant des nombres premiers "sûrs" pour chaque site Web ou serveur.

Quelles sont les meilleures pratiques à suivre pour sécuriser mon serveur conformément aux recommandations ci-dessus?


Réponses:


82

Dans l' article que vous avez lié , trois étapes sont recommandées pour vous protéger contre cette vulnérabilité. En principe, ces étapes s’appliquent à tous les logiciels que vous pouvez utiliser avec SSL / TLS, mais nous traiterons ici des étapes spécifiques pour les appliquer à Apache (httpd), car c’est le logiciel en question.

  1. Désactiver les suites de chiffrement d'exportation

Prise en compte des modifications de configuration que nous effectuerons en 2. ci-dessous ( !EXPORTla fin de la SSLCipherSuiteligne explique comment nous allons désactiver les suites de chiffrement d'exportation)

  1. Déployer (éphémère) Elliptic-Curve Diffie-Hellman (ECDHE)

Pour cela, vous devez modifier quelques paramètres dans vos fichiers de configuration Apache - à savoir SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderd'avoir une configuration « meilleures pratiques ». Quelque chose comme ce qui suit suffira:

SSLProtocol             all -SSLv2 -SSLv3

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-SHA256:AES256-SHA256: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

Remarque: en ce qui concerne le SSLCipherSuiteparamètre à utiliser, cela change constamment, et il est conseillé de consulter des ressources telles que celle-ci pour vérifier la dernière configuration recommandée.

3. Générez un groupe Diffie Hellman puissant et unique

Pour ce faire, vous pouvez exécuter

openssl dhparam -out dhparams.pem 2048.

Notez que cela entraînera une charge importante sur le serveur pendant la génération des paramètres. Vous pouvez toujours contourner ce problème potentiel en générant les paramètres sur une autre machine et en utilisant un moyen scpsimilaire pour les transférer sur le serveur en question.

Pour utiliser ces derniers générés dhparamsdans Apache, à partir de la documentation Apache :

Pour générer des paramètres DH personnalisés, utilisez la commande openssl dhparam. Vous pouvez également ajouter les paramètres DH standard à 1024 bits suivants de la section 6.2 de la norme RFC 2409 au fichier SSLCertificateFile correspondant :

(c'est moi qui souligne)

qui est ensuite suivi par un paramètre DH standard de 1024 bits. Nous pouvons en déduire que les paramètres DH générés sur mesure peuvent simplement être ajoutés au paramètre SSLCertificateFileen question.

Pour ce faire, exécutez quelque chose de similaire à ce qui suit:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Selon la sous - section Apache de l'article que vous avez lié à l'origine, vous pouvez également spécifier le fichier dhparams personnalisé que vous avez créé si vous préférez ne pas modifier le fichier de certificat lui-même, par exemple:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

quelle que soit la ou les configurations Apache qui sont pertinentes pour votre implémentation SSL / TLS particulière - généralement dans conf.d/ssl.confou conf.d/vhosts.confmais cela diffère en fonction de la manière dont vous avez configuré Apache.

Il est à noter que, selon ce lien ,

Avant Apache 2.4.7, le paramètre DH était toujours défini sur 1024 bits et n'était pas configurable par l'utilisateur. Ce problème a été corrigé dans mod_ssl 2.4.7 que Red Hat a rétroporté dans sa distribution RHEL 6 Apache 2.2 avec httpd-2.2.15-32.el6.

Sur Debian Wheezy, mettez à niveau apache2 vers la version 2.2.22-13 + deb7u4 ou ultérieure et ouvre la version 1.0.1e-2 + deb7u17. Le SSLCipherSuite ci-dessus ne fonctionne pas parfaitement, utilisez plutôt ce qui suit selon ce blog :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: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-DSS-AES128-SHA256:DHE-DSS-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:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Vous devez vérifier si votre version d'Apache est postérieure à ces numéros de version en fonction de votre distribution, et si ce n'est pas le cas, mettez-le à jour si possible.

Une fois que vous avez effectué les étapes ci-dessus pour mettre à jour votre configuration et redémarré le service Apache pour appliquer les modifications, vous devez vérifier que la configuration est conforme aux souhaits en exécutant les tests sur SSLLabs et sur l'article associé à cette vulnérabilité particulière.


1
En ce qui concerne la charge placée sur le serveur en générant les paramètres, vous pouvez toujours les générer sur une autre machine et simplement scp ou même copier-coller le fichier sur le serveur cible. Il n'est pas nécessaire de générer les paramètres sur le serveur de production.
Erathiel

2
Après avoir modifié votre configuration, vous pouvez également effectuer une vérification sur SSLLabs.com pour vous en assurer.
user2428118

2
Existe-t-il un moyen de corriger cette vulnérabilité dans Apache / 2.2.22 (Ubuntu 12.04)? J'ai annexé dhparams.pem à certificate.crt mais faihdh.org/sysadmin.html se plaint toujours
envoyé

2
@tersmitten C'est une question complètement distincte de celle-ci.
Michael Hampton

3
vous pouvez toujours exécuter la génération de clé avec la commande 'nice'. vous pouvez donc le résumer ainsi: nice 19 openssl dhparam -out dhparams.pem 2048. Cela fonctionnera plus longtemps, mais ne consommera que du temps processeur non utilisé.
Znik

1

Basé sur un correctif de Winni Neessen, j’ai publié un correctif pour Apache / 2.2.22 (Debian Wheezy, peut-être également utilisable sur Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . pour vos commentaires.


3
c'est plus un bidouillage que une solution. mettre un nginx récent devant votre apache en tant que proxy inverse serait beaucoup plus facile, et on ne s'appuie pas sur un tiers-apache.
Ce gars de là-bas

6
Pourquoi devrions-nous faire confiance à ces binaires?
un CVn

2
Vous n'avez pas à faire confiance aux fichiers binaires; vous pouvez vous recompiler apache2.2.x très facilement en suivant les étapes expliquées si vous prenez le temps. Cela augmenterait en outre votre sécurité, car votre configuration aurait alors des clés primaires uniques.
Flo

Suggérerait que les gens ne se plaignent pas des correctifs corrigeant un problème dans un logiciel opensource
Florian Heigl

@FlorianHeigl Je ne sais même pas quoi faire de ce commentaire ...
BE77Y

-7

Au lieu de suivre la voie complexe des «hacks» ci-dessus, envisagez de passer à nginx en tant que logiciel principal pour votre serveur Web (et pas uniquement la mise en cache ou le proxy). Cela semble évidemment plus conforme aux normes actuelles en matière de sécurité que les anciens moteurs Apache. En utilisant le référentiel nginx, vous obtenez un moteur de serveur Web stable plus moderne qu’apache.

J'ai complètement basculé. Cela m'a fait gagner beaucoup de temps à résoudre les problèmes liés à TLS et, pour nos configurations, à libérer beaucoup de mémoire vive du même coup. En fait, j’ai trouvé l’emploi de nginx simple et rafraîchissant, comparé à la myriade de complications de config de httpd / apache auxquelles je me suis habitué. Peut-être une question de goût, je maîtrisais parfaitement httpd / apache rewrite / config / maintenance avant de me tourner, et c’était plus facile que je ne le craignais. Des informations récentes sur nginx config sont disponibles en ligne, et sa base d'utilisateurs est immense, très active et prend en charge le support. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png


3
nginx configuré pour autoriser les chiffrements d'exportation serait tout aussi vulnérable à l'attaque Logjam qu'un serveur Apache configuré pour autoriser les chiffrements d'exportation. En outre, la question demande des solutions dans Apache.
un CVn

2
En fait, solution: soit vous passez à une distribution offrant des paquetages plus à jour pour les logiciels pour lesquels vous avez absolument besoin d'une version plus récente (pas seulement les corrections de bogues reportées, comme c'est le cas par exemple avec Debian ou CentOS), ou vous construisez vous-même des paquetages. depuis la source (ce n’est pas difficile) et installez-les à l’aide du gestionnaire de paquets, ou d’ installations simples à partir du code source (pas plus difficile, mais cela demande un peu plus de travail à gérer). Pour une question qui demande "comment puis-je atténuer la vulnérabilité X dans le logiciel Y?", Une réponse indiquant "remplacer le logiciel Y par un logiciel Z" n'est souvent pas une réponse utile.
un CVn

1
Apache to Nginx n'est pas une mise à niveau, c'est un remplacement. Le portage est une possibilité. Si vous avez beaucoup de travail investi dans la solution Apache, le rejeter complètement et le remplacer par autre chose demande également beaucoup de travail. Et cette question concerne toujours les solutions centrées sur Apache et non sur Nginx. Je ne vais pas passer plus de temps à discuter à ce sujet; Lorsque vous postez des réponses, assurez-vous qu’elles répondent à la question posée en haut de la page. Si vous souhaitez publier une réponse encourageant les utilisateurs à passer d’Apache à Nginx, ne vous gênez pas, mais posez-la à une question qui permette à Nginx.
un CVn

1
Donc, configurer correctement un logiciel pour qu'il soit sécurisé contre les attaques connues est "une voie complexe de piratage"? Je reçois A + sur ssllabs.com avec une configuration Apache simple, il vous suffit de prendre votre temps et de faire des recherches pour comprendre comment configurer correctement le logiciel que vous utilisez, pas de piratage ici ...
Chazy Chaz

1
@ Julius - les votes négatifs sont probablement davantage liés au manque de valeur de votre réponse concernant la question posée qu'à tout "agenda" caché que les gens pourraient apparemment avoir contre Nginx vs Apache. En l'occurrence, j'utilise exclusivement nginx en raison de ma préférence - mais c'est moi qui ai répondu à cette question. "Passer à un autre logiciel" n'est pas une réponse acceptable à "comment résoudre (n'importe quel problème)". Sans parler de vous, vous avez aussi complètement manqué le point de la vulnérabilité - il s’agissait d’un échange de clé difficile, mais pas d’apache (ni de nginx, ni de sshd, ni ...)
BE77Y, le
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.