Désactiver RC4 dans la suite de chiffrement SSL d'un serveur Apache

Veuillez consulter les sections MODIFIER dans ma propre réponse; ils contiennent une explication à cette énigme .

J'essaie de désactiver RC4 pour un serveur Apache 2.2.9 fonctionnant sur un CentPS 6.5 VPS et je n'arrive pas à réussir.

Un certificat validé par l'entreprise récemment acheté est installé et les connexions SSL fonctionnent bien, mais je voulais configurer les choses aussi bien que possible, pour "renforcer la sécurité" comme le disent certains didacticiels.

En vérifiant la configuration avec Qualys SSL Labs, la page de résultats affiche "Ce serveur accepte le chiffrement RC4, qui est faible. Grade plafonné à B."

Cependant, j'ai mis cela dans ssl.conf:

 SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

J'ai enregistré le script donné dans la réponse à cette question dans un fichier nommé test-ssl-ciphers.sh et changé l'adresse IP en une adresse de bouclage. C'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, selon le script, signifie que le serveur ne prend pas en charge la combinaison de chiffrement spécifiée.

De plus, la commande grep -i -r "RC4" /etc/httpdne me donne que le fichier ssl.conf mentionné ci-dessus.

En outre, l'exécution openssl ciphers -Vsur ma suite de chiffrement ne montre aucun chiffrement RC4, ce qui est logique compte tenu de la chaîne de configuration.

Je suis donc en quelque sorte perdu de savoir pourquoi les sites de vérification SSL me disent que "le serveur accepte RC4". Ils énumèrent même les chiffres suivants comme étant acceptés:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Quelqu'un at-il une explication possible? Qu'est-ce que je fais mal? Peut-être y a-t-il un autre endroit où ce support de RC4 ou "acceptation" soit configuré?

Merci.

[ EDIT ] À l'aide d'un CentOS 6.6 dans une machine virtuelle à la maison, j'ai exécuté à nouveau le script sur mon VPS en utilisant son nom de domaine au lieu de l'adresse de bouclage. Cette configuration implique que la liste des chiffres est fournie par l'instance openssl dans la machine virtuelle: je n'ai toujours pas RC4 parmi les chiffres qui donnent OUI.

Lors de l'installation du certificat renouvelé, j'ai découvert que le problème était dû à la spécification (pour le domaine et pour chaque sous-domaine) dans ISPConfig de l'ensemble des données nécessaires pour HTTPS: certificat, clé privée, chaîne d'autorité de certification, etc.

Autrement dit, la suppression de l'ensemble de données a conduit au test Qualys pour noter le domaine A et en même temps supprimer les avertissements concernant RC4. Remettre les détails entraîne le retour des avertissements et le plafonnement de la note à B, ce qui ne laisse aucun doute sur le lien de causalité.

C'est comme si le fait de donner les détails de chaque vhost créait en quelque sorte un nouvel environnement dans lequel certains paramètres par défaut ont outrepassé 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 des directives Apache pour chaque vhost. C'est ce que j'ai dans la configuration qui me donne 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 SSLCipherSuiteest obligatoire. Je ne peux pas comprendre 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 SSLCipherSuitedirective 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 (sur CentOS 6, le fichier se trouve à /etc/httpd/conf.d/ssl.conf), il vous suffit de spécifier la directive en dehors de l'hôte virtuel par défaut. La documentation 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 vient le chiffrement RC4: en l'absence de toute spécification, ce qui était le cas pour moi car aucune spécification n'était dans le contexte "global", la valeur par défaut s'applique. 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 en quelque sorte perdu de savoir pourquoi les sites de vérification SSL me disent que "le serveur accepte RC4". Ils énumèrent même les chiffres suivants comme étant acceptés:

Assurez-vous que vos tests local et externe accèdent tous les deux au même serveur (adresse IP). J'ai vu beaucoup de sites example.comsur un hôte différent de celui-ci www.example.comet les tests diffèrent donc.

Les laboratoires SSL Qualys semblent très sensibles aux hôtes par défaut, etc. Vérifiez que TOUS vos hôtes virtuels HTTPS sur cette adresse IP utilisent exactement les mêmes paramètres (à l'exception des fichiers de certificat), j'ai eu un problème similaire où certains des tests Qualys ont été testés par rapport à mon hôte virtuel ciblé et certains des tests semblaient prendre un VirtualHost par défaut. Mon vhost ciblé n'avait qu'un seul chiffrement activé, mais Qualys trouvait une liste beaucoup plus longue à partir du vhost par défaut.

J'ai également trouvé un script plus beau ici qui donne des informations plus détaillées sur les tests SSL.

Je cherchais juste à travers cela pour l'un de mes sites. Sur la base de la réponse de @ AbVog, j'ai trouvé que mes directives n'étaient en fait qu'à l'intérieur du vhost par défaut. Lorsque j'ai déplacé les directives dans le contexte mondial, tout s'est bien passé.

En passant, je suis également tombé sur https://cipherli.st/ qui a une bonne liste de configuration SSL pour un tas de packages différents. La recommandation actuelle pour apache comme suit:

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 chiffres sont gérés par les crypto-politiques (voir / etc / cryptopolicies / backends). La configuration par défaut a RC4 complètement désactivé, donc pas besoin de falsifier les chiffres dans la configuration Apache. Sauf à vous assurer que vous utilisez le dernier ssl.conf car il n'est pas installé par défaut mais laissé en tant que ssl.conf.rpmnew dans le répertoire conf.d.

Afin de configurer SSL, je devais juste spécifier les certificats, ServerName et DocumentRoot. Pour Squirrelmail, c'est.

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"