Correction de la vulnérabilité BEAST sur Apache 2.0 fonctionnant sur RHEL 4

11

J'ai un serveur Web exécutant Apache 2.0 sur RHEL4. Ce serveur a récemment échoué une analyse PCI.

Raison: SSLv3.0 / TLSv1.0: faiblesse du mode CBC Solution: cette attaque a été identifiée en 2004 et dans les révisions ultérieures du protocole TLS qui contiennent un correctif. Si possible, effectuez une mise à niveau vers TLSv1.1 ou TLSv1.2. Si la mise à niveau vers TLSv1.1 ou TLSv1.2 n'est pas possible, la désactivation des chiffrements en mode CBC supprimera la vulnérabilité. L'utilisation de la configuration SSL suivante dans Apache atténue cette vulnérabilité: SSLHonorCipherOrder Sur SSLCipherSuite RC4-SHA: HIGH:! ADH

Solution simple, je pensais. J'ai ajouté les lignes à la configuration Apache et cela n'a pas fonctionné. Apparemment,
"SSLHonorCipherOrder On" ne fonctionnera que sur Apache 2.2 et versions ultérieures. J'ai essayé de mettre à niveau Apache, je suis vite tombé dans l'enfer des dépendances et il semble que je devrai mettre à niveau l'ensemble du système d'exploitation pour passer à Apache 2.2. Nous retirons ce serveur dans quelques mois donc ça ne vaut pas le coup.

La solution dit "Si la mise à niveau vers TLSv1.1 ou TLSv1.2 n'est pas possible, la désactivation des chiffrements en mode CBC supprimera la vulnérabilité."

Comment pourrais-je faire cela sur Apache 2.0? Est-ce seulement possible? Sinon, existe-t-il d'autres solutions?

apache-2.2 ssl tls

— Debianuser
source

3

Étant donné que la prise en charge étendue des mises à jour pour RHEL4 (.7) a pris fin il y a un an, je suggère de retirer le serveur plus tôt que tard. Sinon, vous devrez probablement construire apache 2.2 à partir des sources.

— DerfK

Le nouveau serveur est prêt mais nous ne pouvons pas migrer avant décembre. Oui, la compilation et l'installation d'Apache 2.2 à partir des sources est la dernière option pour l'instant. Je me demandais s'il y avait une solution plus simple à contourner?

— Debianuser

11

Autre que de compiler un Apache plus récent à la main, la seule chose à laquelle je peux penser serait de faire de RC4-SHA le seul chiffrement pris en charge (testé avec openssl ciphers RC4-SHAsur l'OpenSL actuel pour s'assurer qu'il n'imprime qu'un seul chiffrement, vous voudrez peut-être faire la même chose pour vous assurer qu'il ne correspond pas à un vieux chiffrement étrange sur votre ancien openssl):

SSLCipherSuite RC4-SHA

MS dit que Windows XP prend en charge TLS_RSA_WITH_RC4_128_SHA , vous ne devriez donc pas avoir de problèmes de compatibilité.

— DerfK
source

1

Exactement ce que je cherchais. J'ai testé avec succès en utilisant beast-check.googlecode.com/files/beast.pl . Je planifierai une analyse PCI et je vous ferai savoir une fois l'opération terminée.

— Debianuser

Je peux confirmer que cela a fonctionné. Le serveur a réussi une analyse PCI. Merci beaucoup.

— Debianuser

6

Il n'y a que deux façons de "réparer" BEAST au niveau du serveur.

La meilleure option consiste à mettre à niveau la bibliothèque SSL de votre serveur vers une bibliothèque qui prend en charge TLS v1.1 ou version ultérieure (et assurez-vous que vos clients la prennent également en charge, afin que vous puissiez les forcer à l'utiliser).

L'autre option consiste à désactiver tous les algorithmes de cryptage CBC (Cypher-Block-Chaining) et à basculer vers un cryptage en ECB (Electronic Code Book) ou quelque chose comme RC4 (les algorithmes ECB sont théoriquement "moins sûrs" car une entrée en texte clair donnée est cryptée pour une donnée donnée). key renvoie toujours au même cryptage, ce qui facilite la rupture avec les attaques connues en texte brut, mais en pratique, cela ne devrait pas être un problème énorme. Google (à titre d'exemple) utilise toujours RC4).

Étant donné que le serveur que vous utilisez est mort, enterré et en décomposition, cela ne vaut probablement pas la peine qu'il faudrait pour créer un Apache corrigé (vous devrez reconstruire Apache et OpenSSL de manière isolée, afin de ne pas perturber quoi que ce soit qui nécessite la version d'OpenSSL installée sur votre système par défaut - Si vous faites autant de travail, vous pouvez aussi bien mettre à niveau l'ensemble du système vers quelque chose qui est réellement pris en charge), de sorte que vous laisse à peu près "Switch to ECB Cyphers" comme votre solution viable.

BEAST est vraiment un burger rien d'une attaque ces jours-ci - Tous les navigateurs populaires (IE, Chrome, Safari, Opera) ont mis en œuvre une solution de contournement efficace , et en raison du fonctionnement de l'attaque, il est assez difficile à mettre en œuvre en dehors d'un navigateur (donc aptet yumsont encore à peu près sûrs).

Adam Langley de Google a prononcé un excellent discours plus tôt cette année, qui décrit certains des problèmes que vous devriez vous concentrer sur re: SSL et la sécurité - Bien que BEAST ait mérité une mention, il était près du bas de la liste des sujets de préoccupation.

— voretaq7
source

RC4 n'est pas un chiffrement en mode ECB. L'utilisation du mode ECB serait une énorme erreur, et il y a de bonnes raisons que TLS n'ait pas de suites de chiffrement ECB prises en charge. Utiliser un chiffrement de flux comme RC4 est une idée beaucoup moins mauvaise, bien que les résultats récents signifient qu'il semble moins beau qu'il ne l'était isg.rhul.ac.uk/tls

— armb

4

La seule solution que j'ai trouvée qui vous fera passer le test ssllabs.com consiste à ajouter les quatre lignes suivantes à votre http://.conf apache et à vos fichiers ssl.conf:

SSLHonorCipherOrder On

SSLProtocol -all + TLSv1 + SSLv3

SSLCipherSuite RC4-SHA: HIGH:! MD5:! ANULL:! EDH:! ADH

SSLInsecureRenegotiation off

Assurez-vous qu'aucun de ces paramètres n'est publié deux fois dans le fichier ssl.conf.

Maintenant, mes sites passent avec un A.

— user2183769
source