Désactivation de RC4 dans la suite de chiffrement SSL d'un serveur Apache
Veuillez consulter les sections EDIT de ma propre réponse. ils contiennent une explication à cette énigme .
J'essaie de désactiver RC4 pour un serveur Apache 2.2.9 s'exécutant sur un VPS CentOS 6.5 et je ne peux pas sembler réussir.
Un certificat validé par l'entreprise récemment acheté est installé et les connexions SSL fonctionnent correctement, mais je voulais configurer le mieux possible, pour "renforcer la sécurité", comme le disent certains tutoriels.
En vérifiant la configuration avec Qualys SSL Labs, la page de résultats indique "Ce serveur accepte le chiffrement RC4, qui est faible. Grade limité à B."
Cependant, j'ai mis ceci dans ssl.conf:
SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
J'ai sauvegardé le script donné dans la réponse à cette question dans un fichier nommé test-ssl-ciphers.sh et j'ai changé l'adresse IP en une adresse de bouclage . Ceci est le résultat de ./test-ssl-ciphers.sh | grep -i "RC4":
Testing ECDHE-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDHE-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing AECDH-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing ECDH-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDH-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing PSK-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-MD5...NO (no ciphers available)
Testing EXP-ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-KRB5-RC4-SHA...NO (no ciphers available)
Testing EXP-KRB5-RC4-MD5...NO (no ciphers available)
Chacune de ces lignes contient "NO", ce qui signifie, selon le script, que le serveur ne prend pas en charge la combinaison de chiffrement spécifiée.
De plus, la commande grep -i -r "RC4" /etc/httpd ne me donne que le fichier ssl.conf mentionné ci-dessus.
De plus, exécuter openssl ciphers -V sur ma suite de chiffrement ne montre aucun chiffrement RC4, ce qui est logique compte tenu de la chaîne de configuration.
Je suis donc quelque peu perdu la raison pour laquelle les sites Web de vérification SSL me disent que "le serveur accepte RC4". Ils indiquent même que les chiffres suivants sont acceptés:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
Est-ce que quelqu'un a une explication possible? Qu'est-ce que je fais quelque chose de mal? Peut-être y at-il un autre endroit où le support de RC4 ou "acceptation" sera configuré?
Merci.
[EDIT] En utilisant une CentOS 6.6 dans une machine virtuelle à la maison, j'ai réexécuté le script sur mon VPS en utilisant son nom de domaine à la place de l'adresse de bouclage. Cette configuration implique que la liste des chiffrements est fournie par l'instance openssl de la machine virtuelle: je n'ai toujours pas de RC4 parmi les chiffrements générant YES.
Lors de l'installation du certificat renouvelé, j'ai découvert que le problème découlait de la spécification (pour le domaine et pour chaque sous-domaine) dans ISPConfig de l'ensemble des données nécessaires à HTTPS: certificat, clé privée, chaîne d'autorité de certification, etc.
En d'autres termes, la suppression de l'ensemble de données a conduit le test Qualys à évaluer le domaine A et à supprimer simultanément les avertissements relatifs à RC4. Le fait de remettre les détails en arrière conduit au retour des avertissements et au fait que la note est de nouveau plafonnée à B, ce qui ne laisse aucune place au doute quant au lien de causalité.
C'est comme si la communication des détails de chaque vhost créait en quelque sorte un nouvel environnement dans lequel certaines valeurs par défaut remplaçaient la suite de chiffrement que j'ai spécifiée dans ssl.conf. Bizarre.
La solution consiste à ajouter la spécification SSLCipherSuite dans la zone de texte Directives Apache pour chaque hôte virtuel. Voici ce que j'ai dans la configuration qui me permet d'obtenir une note A:
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
# Compression is disabled by default on my distribution (CentOS 6)
# SSLCompression off
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
EDIT (2017-05-16): Une conclusion supplémentaire à propos de ce problème: la spécification de SSLCipherSuite est obligatoire. Je ne comprends pas pourquoi cette directive spécifique, bien que spécifiée au niveau du serveur, ne s'applique pas automatiquement aux configurations d'hôte virtuel . J'utilise Apache 2.2.15 sur CentOS 6.9.
EDIT (2018-06-18): Plus d'informations. Je viens de découvrir que la directive SSLCipherSuite peut être spécifiée une seule fois et qu'elle s'appliquera à tous les hôtes virtuels: dans le fichier de configuration de base mod_ssl (sous CentOS 6, le fichier se trouve à /etc/httpd/conf.d/ssl.conf), il vous suffit de spécifier la directive en dehors de de l'hôte virtuel par défaut. La documentation d'Apache 2.2 indique que la valeur par défaut de cette directive est SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. Je pense que c'est de là que provient le chiffrement RC4: en l'absence de toute spécification, ce qui était le cas pour moi, car aucune spécification ne se trouvait dans le contexte "global", la valeur par défaut est appliquée. Cette compréhension met fin à ce qui a été un mystère pour moi. Ironiquement, je suis sur le point de passer à CentOS 7 lorsque je trouve cette explication! HTH.
SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
^^^^^^^
Mauvaise idée. La désactivation de tous les chiffrements SSLv3 entraîne la désactivation des chiffrements utilisables avec TLS1.0 et TLS1.1 et ne laisse que quelques chiffrements nouvellement introduits avec TLS1.2 (si votre serveur prend en charge TLS1.2)
Je suis donc quelque peu perdu la raison pour laquelle les sites Web de vérification SSL me disent que "le serveur accepte RC4". Ils indiquent même que les chiffres suivants sont acceptés:
Assurez-vous que les tests locaux et externes accèdent tous les deux au même serveur (adresse IP). J'ai vu beaucoup de sites où example.com est sur un hôte différent de www.example.com et donc les tests diffèrent.
Les laboratoires SSL Qualys semblent très sensibles aux hôtes par défaut, etc. Vérifiez que TOUS vos hôtes virtuels HTTPS utilisant cette adresse IP utilisent exactement les mêmes paramètres (à l'exception des fichiers de certificat). J'ai eu un problème similaire. certains des tests semblaient prendre un VirtualHost par défaut. Mon vhost ciblé n'avait qu'un seul chiffre activé, mais Qualys trouvait une liste beaucoup plus longue à partir du vhost par défaut.
J'ai également trouvé un meilleur script ici qui donne des informations plus complètes sur les tests SSL.
Je cherchais simplement l'un de mes sites. Sur la base de la réponse de @ AbVog, j'ai constaté que mes directives ne se trouvaient en réalité que dans le vhost par défaut. Lorsque j'ai déplacé les directives dans le contexte global, tout allait bien.
En passant, je suis également tombé sur https://cipherli.st/ , qui possède une bonne liste de configurations SSL pour différents paquets. La recommandation actuelle pour Apache est la suivante:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLSessionTickets Off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Sur mon Fedora 25 avec Apache/2.4.25, les chiffrements sont gérés par les politiques de chiffrement (voir/etc/cryptopolicies/backends). La configuration par défaut a complètement désactivé RC4, il n’est donc pas nécessaire de modifier les chiffrements dans la configuration d’Apache. Sauf à vous assurer que vous utilisez le dernier fichier ssl.conf, car il n'est pas installé par défaut mais laissé comme ssl.conf.rpmnew dans le répertoire conf.d.
Afin de configurer SSL, il me suffisait de spécifier les certificats ServerName et DocumentRoot. Pour Squirrelmail, c’est le cas.
SSLCertificateFile /etc/letsencrypt/live/mail.xxxx.dk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.xxxx.dk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.xxxx.dk/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/mail.xxxx.dk/fullchain.pem
ServerName mail.xxxx.dk:443
DocumentRoot "/usr/share/squirrelmail"