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é.
Il y a bien longtemps que SSL est dépassé,
remplacé par TLS (même si des ignorants
continuent de parler de SSL dès qu'ils voient un petit cadenas sur
leur navigateur Web). Mais les vieux protocoles ne meurent pas
facilement sur l'Internet. Manque de ressources humaines qualifiées,
absence d'intérêt pour la sécurité, blocage par la direction
financière qui demande quel est le ROI, des tas
de raisons font que pas mal de serveurs acceptent encore le SSL
v3. Celui-ci, décrit dans le RFC 6101 (mais qui avait été
défini et déployé bien avant, en 1996, le RFC 6101 ne faisant que
documenter longtemps après), devrait pourtant être abandonné
définitivement, ne laissant que TLS (dont la
version actuelle est la 1.2, en RFC 5246).
La première fin de SSL v3 était en 1999,
avec la sortie de TLS, dans le RFC 2246. Le fait que SSL v3
soit toujours bien vivant aujourd'hui, plus de quinze ans après, donne une idée de l'ossification
de l'Internet et du manque de réactivité des techniciens.
La section 3 de notre RFC résume la bonne pratique actuelle :
NE PAS UTILISER SSL v3. Les clients ne doivent
pas le proposer dans le ClientHello, ni les
serveurs dans leur ServerHello.
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).
Comme le notait le texte d'accompagnement à
l'IESG, où on doit indiquer les mises en œuvre
du protocole, « Are there existing implementations of the protocol? Yes, and
that's the problem;-) ». Ceci dit, une bonne partie des
déploiements de TLS ont commencé à supprimer SSL v3. Logiquement, il
devrait être retiré du code des bibliothèques TLS (alors que, encore
aujourd'hui, la page d'accueil de GnuTLS se
vante de gérer SSL v3). Espérons que ce RFC, qui n'apporte aucune
information technique nouvelle, par son côté « officiel », contribue à
faire bouger les choses.
Pour déterminer si un serveur accepte SSL v3, on peut utiliser le
client d'OpenSSL :
% openssl s_client -connect www.bortzmeyer.org:443 -ssl3
CONNECTED(00000003)
depth=0 CN = www.bortzmeyer.org
...
SSL handshake has read 2276 bytes and written 470 bytes
...
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID: 8B815B79611AB6FB105E84AA3159A0E57D50BA61BEE33478BB5DFEAFD5E4979B
Ici, le serveur a accepté SSL v3 (
handshake
terminé, algorithme de chiffrement
-
DHE-RSA-AES256-SHA - sélectionné alors qu'on a
forcé SSL v3). Si vous voulez savoir pourquoi
ce serveur particulier accepte malheureusement SSL v3, voir à la fin de cet article.
Avec un qui n'a pas SSL v3, on voit :
% openssl s_client -connect www.example.net:443 -ssl3
CONNECTED(00000003)
3073382076:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
...
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Les messages d'OpenSSL, comme toujours, sont peu clairs, mais on peut
voir que le
handshake n'a pas abouti (très peu de
données transmises), qu'aucun algorithme de chiffrement n'a été choisi
et qu'aucune session n'a commencé (ID vide). Ce serveur est donc correct.
Notez que l'administrateur système est
dépendant des logiciels utilisés et qu'il ne peut pas tout
reprogrammer lui-même. Ainsi, GnuTLS a un
module Apache,
mod_gnutls, qui a une très sérieuse bogue
(ancienne et jamais réparée) qui fait que SSLv3 n'est pas interdit,
même quand la configuration le demande.
Personnellement, je vais arrêter d'utiliser GnuTLS sur mes sites Web,
pas à cause de la bibliothèque elle-même, qui est excellente, mais à cause de ce module Apache pas maintenu.
