« Ce nouveau RFC formalise un point déjà bien connu des experts en sécurité : le dernier survivant de la famille SSL, SSL version 3, a de graves failles et ne doit pas être utilisé.

[...]

Bien plus longue, la section 4 décrit pourquoi SSL v3 est cassé sans espoir de réparation. Première raison, qui a permis la faille POODLE (cf. un bon article d'explication pour tous), c'est que le remplissage en mode CBC n'est pas spécifié (et donc pas vérifiable par le pair). Autre faille, SSL v3 fait forcément du MAC-then-encrypt, ce qui est aujourd'hui considéré comme dangereux. TLS fait aussi du MAC-then-encrypt par défaut mais on peut le changer (RFC 7366) grâce aux extensions. Or, SSL v3 n'a pas la notion d'extensions.

Les algorithmes de chiffrement stream de SSL v3 ont tous des défauts sérieux, par exemple RC4 est désormais officiellement abandonné (RFC 7465). Question condensation, ce n'est pas mieux, certaines opérations de SSL v3 imposant MD5 (RFC 1321, abandonné par le RFC 6151).

L'échange de clés dans SSL v3 a aussi des failles permettant à un homme du milieu de se placer. Corrigées dans TLS par des extensions, elles ne sont pas corrigeables en SSL v3.

Toujours en raison de son manque d'extensibilité, SSL v3 ne peut pas avoir certaines des nouvelles fonctions développées depuis sa naissance. Pas d'algorithmes dans les modes AEAD (RFC 5246, section 6), pas de courbes elliptiques (RFC 4492), pas de reprise d'une session existante sans état sur le serveur (RFC 5077), pas de mode datagramme pour UDP (RFC 6347), pas de négociation de l'application utilisée (RFC 7301). »
(Permalink)

(Permalink)