Quelles sont les principales vulnérabilités de TLS v1.1?
Quelles sont les principales vulnérabilités de TLS v1.1? En fait, aucune RFC ne décrit les vulnérabilités de la v1.1, ni ce qui les a poussées à passer au nouveau protocole 1.2, sauf la description donnée dans la section 1.2 de RFC 5246 .
Veuillez noter que je ne parle pas de vulnérabilités de mise en œuvre, je ne cherche que des problèmes avec le protocole lui-même.
Il n'y a pas de "vrai" problème de sécurité dans TLS 1.1 que TLS 1.2 corrige. Cependant, il y a des changements et des améliorations, qui peuvent être argumentés pour être qualifiés de "fixage". Principalement:
Le PRF dans TLS 1.1 est basé sur une combinaison de MD5 et SHA-1. Les fonctions MD5 et SHA-1 sont, en tant que fonctions de hachage cryptographique, rompues. Cependant, la façon dont ils sont brisés ne rompt pas le PRF de TLS 1.1. Il n'y a pas de faiblesse connue dans le PRF de TLS 1.1 (ni d'ailleurs dans le PRF de SSL 3.0 et TLS 1.0). Néanmoins, MD5 et SHA-1 sont de la "mauvaise presse". TLS 1.2 remplace les deux par SHA-256 (enfin, il pourrait s'agir de n'importe quelle autre fonction de hachage, mais en pratique, c'est SHA-256).
TLS 1.2 permet l'utilisation de modes de chiffrement authentifiés comme GCM. Cela peut remplacer le mode de cryptage CBC plus traditionnel, qui a toujours été une source de nombreuses failles. Correctement implémenté Le cryptage CBC est toujours bien; cependant, il semble que la mise en œuvre correcte du chiffrement CBC soit plus facile à dire qu'à faire. Obtenir un GCM correct semble être un objectif plus facilement réalisable.
TLS 1.2 impose la prise en charge de
TLS_RSA_WITH_AES_128_CBC_SHAalors que TLS 1.1 n'exigeait queTLS_RSA_WITH_3DES_EDE_CBC_SHA. Ainsi, si vous utilisez TLS 1.2, vous avez une "garantie" que le cryptage AES sera disponible. (Ce n'est en fait pas tout à fait vrai: la garantie n'est valable que tant qu'aucun "profil spécifique à l'application" ne l'exige. En outre, vous n'obtiendrez AES que si le client et le serveur le prennent en charge, et s'ils le supportent tous les deux, alors c'est le cas. disponible, que TLS 1.1 ou 1.2 soit utilisé.)
Pour résumer , ce n'est pas une mauvaise idée de patcher vos serveurs pour prendre en charge TLS 1.2 et de les configurer pour le préférer à TLS 1.1, mais il n'y a pas de véritable faille dans TLS 1.1 qui nécessitait une correction et rendrait obligatoire le passage à TLS 1.2 ou même recommandé. Le principal moteur de l'adoption de TLS 1.2 est le désir pavlovien habituel de tout ce qui est nouveau et brillant.
Rester avec TLS 1.0 est une très mauvaise idée et assez dangereux. Peut aussi être POODLEd, BEASTed et autrement rembourré-Oracled. De nombreuses autres faiblesses CVE s'appliquent toujours et ne peuvent être corrigées que si vous désactivez TLS 1.0.
Rester avec TLS 1.1 n'est qu'un mauvais compromis bien qu'il soit à moitié exempt de problèmes TLS 1.0 (mais comme les deux protocoles ne fournissent aucun mode de code moderne qui est essentiel aujourd'hui, les méthodes de cryptage modernes ne fonctionnent pas ici)
TLS 1.2 avec CBC Ciphers ON et aussi RSA on est une sorte de jeu de loterie que vos connexions soient entièrement sécurisées ou non. Cela dépend de la façon dont les chiffres sont implémentés de chaque côté de la connexion (serveur <-> Clientbrowser).
Mode de fonctionnement recommandé pour l'instant: TLS 1.2 sans chiffrement CBC (ce qui signifie également que les poignées de main RSA sont désactivées) est suffisamment sûr, seul TLS 1.3 est plus sûr en raison de son amélioration de la gestion et de l'exclusion de tout ce qui est devenu obsolète depuis la mise en place de TLS 1.2.
(en supposant que tous les autres 64 bits dangereux, y compris les chiffres 3DES et RC4, sont déjà désactivés)