web-dev-qa-db-fra.com

Comment corriger la vulnérabilité «logjam» dans Apache (httpd)

Récemment, une nouvelle vulnérabilité dans Diffie-Hellman, appelée officieusement "logjam" a été publiée, pour laquelle cette page a été mise en place, suggérant comment contrer la vulnérabilité:

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

  1. Désactiver les suites de chiffrement d'exportation. Même si les navigateurs modernes ne prennent plus en charge les suites d'exportation, les attaques FREAK et Logjam permettent à un attaquant de niveau intermédiaire de tromper navigateurs à utiliser la cryptographie de qualité export, après quoi la connexion TLS peut être déchiffrée. Les chiffres d'exportation sont un vestige de la politique des années 1990 qui empêchait l'exportation de protocoles cryptographiques solides des États-Unis. Aucun client moderne ne compte 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). Elliptic-Curve Diffie-Hellman (ECDH) l'échange de clés évite toutes les attaques cryptanalytiques réalisables connues, et les navigateurs Web modernes préfèrent désormais ECDHE au diffuseur d'origine Diffie-Hellman. Les algorithmes de journalisation discrets que nous avons utilisés pour attaquer les groupes Diffie-Hellman standard ne bénéficient pas d'un avantage aussi important du précalcul, et les serveurs individuels n'ont pas besoin de générer des courbes elliptiques uniques.
  3. Générez un groupe Diffie Hellman fort et unique . Quelques groupes fixes sont utilisés par des millions de serveurs, ce qui en fait une cible optimale pour le précalcul et les écoutes potentielles. Les administrateurs doivent générer des groupes Diffie-Hellman uniques, 2 048 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?

apache-2.2sslapache-2.4httpdvulnerability
56
Christophe De Troyer

D'après article que vous avez lié , il existe trois étapes recommandées pour vous protéger contre cette vulnérabilité. En principe, ces étapes s'appliquent à tout logiciel que vous pouvez utiliser avec SSL/TLS, mais nous traiterons ici des étapes spécifiques pour les appliquer à Apache (httpd), car il s'agit du logiciel en question.

  1. Désactiver l'exportation des suites de chiffrement

Traitée dans les changements de configuration que nous ferons en 2. ci-dessous (!EXPORT vers la fin de la ligne SSLCipherSuite est la façon dont nous désactiverons les suites de chiffrement d'exportation)

  1. Déployer (éphémère) Diffie-Hellman à courbe elliptique (ECDHE)

Pour cela, vous devez éditer quelques paramètres dans vos fichiers de configuration Apache - à savoir SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder pour avoir une configuration "best-practices". 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 paramètre SSLCipherSuite à utiliser, cela change toujours, et c'est une bonne idée 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 fort et unique

Pour ce faire, vous pouvez exécuter

openssl dhparam -out dhparams.pem 2048.

Notez que cela mettra 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 scp ou similaire pour les transférer sur le serveur en question pour utilisation.

Pour utiliser ces dhparams nouvellement générés dans 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 RFC 2409, section 6.2 au fichier SSLCertificateFile respectif fichier :

(c'est moi qui souligne)

qui est ensuite suivi d'un paramètre DH standard de 1024 bits. De cela, nous pouvons déduire que les paramètres DH générés sur mesure peuvent simplement être ajoutés au SSLCertificateFile en question.

Pour ce faire, exécutez quelque chose de semblable au suivant:

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

Alternativement, 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, ainsi:

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

dans la ou les configurations Apache pertinentes pour votre implémentation SSL/TLS particulière - généralement dans conf.d/ssl.confou conf.d/vhosts.conf mais cela variera selon la façon dont vous avez configuré Apache.

Il est à noter que, selon ce lien ,

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

Sur Debian Wheezy, mettez à niveau Apache2 vers 2.2.22-13 + deb7u4 ou version ultérieure et openssl vers 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 sinon - la mettre à 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 comme vous le souhaitez en exécutant les tests sur SSLLabs et sur l'article lié à cette vulnérabilité particulière.

82
BE77Y

Basé sur un patch 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.

1
Flo