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

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?

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)

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

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.

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