Existe-t-il un moyen d'atténuer BEAST sans désactiver complètement AES?
Il semble que le moyen le plus simple de protéger les utilisateurs contre l'attaque BEAST sur TLS <= 1.0 soit de préférer RC4 ou même de désactiver toutes les autres suites de chiffrement (CBC), par exemple en spécifiant quelque chose comme
SSLCipherSuite RC4-SHA:HIGH:!ADH
dans la configuration Apache mod_ssl.
Cependant, le problème avec CBC semble avoir été résolu dans TLS> = 1.1; Existe-t-il un moyen de (ré) activer ces chiffres pour les clients prétendant prendre en charge TLS 1.1 ou 1.2? Il semble y avoir une solution:
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
qui fait l'affaire en spécifiant des suites de chiffrement qui ne sont disponibles que dans TLS> = 1.1. Cela semble avoir pour effet secondaire d'empêcher les clients TLS> = 1.1 d'utiliser l'une des "anciennes" suites de chiffrement.
Existe-t-il vraiment aucun moyen de dire explicitement à mod_ssl d'utiliser des chiffrements en mode CBC pour TLS> = 1.1, mais seulement RC4 pour SSL/TLS <= 1.0? Cela semblerait être une combinaison optimale de sécurité et de compatibilité.
Une façon d'atténuer BEAST est de ne rien faire . Il se trouve que bien que la vulnérabilité utilisée dans BEAST soit toujours là, son exploitation est plutôt difficile. Cela nécessite la capacité de faire des requêtes inter-domaines, avec un haut niveau de contrôle sur les données envoyées dans la requête; en particulier, il a besoin de données "binaires". Duong et Rizzo n'ont pas trouvé de moyen de cartographier l'attaque sur la plaine <img> tags (Javascript hostile qui produit de telles balises, avec un chemin choisi par l'attaquant: le chemin obtient dans la requête, mais il est uniquement en texte). Dans leur démonstration, ils pourraient utiliser deux trous interdomaines, l'un dans une version préliminaire de WebSockets, l'autre dans l'implémentation de Java d'Oracle. Les deux trous ont depuis été corrigés, donc, à droite maintenant, BEAST ne s'applique plus (sauf si vous n'avez pas mis à jour votre navigateur pendant plus d'un an, auquel cas vous avez probablement de plus gros problèmes).
Étant donné que s'appuyer sur l'inexistence de vulnérabilités interdomaines est, au mieux, fragile, les fournisseurs de navigateurs ont également inclus des contre-mesures supplémentaires, avec fractionnement des enregistrements . Lorsque le navigateur veut envoyer un bloc de n octets de données, au lieu de le mettre dans un enregistrement SSL, il le divise en deux enregistrements, le premier étant très petit. Les limites d'enregistrement n'ont aucune signification sémantique dans SSL/TLS, vous pouvez donc effectuer un tel fractionnement sans changer la signification. Cependant, chaque enregistrement se termine par un MAC calculé sur les données d'enregistrement et un numéro de séquence, et en utilisant une clé dérivée de l'échange de clés initial. Cela agit en quelque sorte comme un générateur de nombres pseudo-aléatoires. Par conséquent, le petit enregistrement "émule" la génération IV aléatoire qui rend TLS 1.1+ immunisé contre BEAST.
Idéalement, la répartition serait 0/n: un enregistrement sans données (mais toujours avec un MAC), suivi d'un enregistrement avec les données réelles. Les enregistrements de longueur nulle sont autorisés (conformément à la standard ) mais les implémentations client et serveur boguées ne les tolèrent pas (en particulier IE 6.0); à la place, les navigateurs utilisent un 1/n-1 split, ce qui est tout aussi bon pour vaincre BEAST, mais fonctionne également avec presque tous les clients et serveurs SSL/TLS existants. Au moins Chrome et Firefox l'ont poussé l'année dernière .
La bonne solution est TLS 1.1 + mais même sur SSL 3.0 et TLS 1.0, le problème BEAST peut être considéré comme résolu, au moins dans le contexte Web. Par conséquent, utilisez AES et soyez heureux.
OpenSSL a un atténuation pour BEAST qui est activé par défaut depuis 0.9.6d, donc tant que votre version d'OpenSSL est cette version ou une version ultérieure et que vous n'avez pas défini SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS il n'est pas nécessaire de restreindre les chiffres ou de désactiver TLS 1.0.
Ma compréhension est que TLS <1.1 avec n'importe quel chiffrement de bloc en mode CBC est vulnérable à BEAST. Encore une fois, à ma connaissance, vos seules options sont d'utiliser TLS 1.1 ou supérieur, ou d'utiliser un chiffrement de flux.
Ou bien sûr, vous pouvez utiliser un protocole différent qui n'est pas affecté par BEAST, comme SSH :)