Aujourd'hui a été publiée la faille de sécurité Drown,
touchant notamment la bibliothèque cryptographique
OpenSSL. C'est l'occasion de se livrer à
quelques réflexions sur Drown, TLS et la
sécurité.
Le même jour, huit (!) failles de sécurité dans
OpenSSL ont été publiées (Drown a été
éclaté en deux failles, CVE-2016-0800 et CVE-2016-0703). Cela ne
facilite pas le travail de ceux qui essaient de démêler tout cela
mais Drown est très bien
documenté sur son site officiel (très complet, avec logo et
tout). Je recommande également le papier
officiel, très clair. Il n'y a normalement donc pas besoin
de ré-expliquer ce qu'est Drown.
Pourtant, je suis étonné de
constater que certaines choses n'ont pas été comprises. Par
exemple bien des gens croient que, puisque leur serveur
HTTPS n'accepte pas SSLv2, ils sont en
sécurité. Rien n'est plus faux et c'est bien expliqué dans la FAQ
de Drown : pour effectuer cette attaque, il suffit que la clé du
site visé soit disponible sur un autre site, qui, lui, accepte
SSLv2. Et, c'est là un point qui m'a personnellement surpris, ce
cas est assez fréquent. Comme le note l'article Drown, le modèle
de financement des AC encourage à acheter
le moins de certificats possibles, et donc à les utiliser sur
plusieurs serveurs, ou bien sur le serveur de production et sur
celui de développement.
Prenons un exemple : le serveur du journal quotidien
Ouest-France n'est apparemment pas
vulnérable, il ne gère pas SSLv2 :
% openssl s_client -connect www.ouest-france.fr:443 -ssl2
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 48 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv2
Cipher : 0000
...
Mais on trouve, sur un tout autre réseau, une machine
93.17.51.145 qui, elle, acceptait (elle a été
réparée depuis) SSLv2 et a un
certificat
*.ouest-france.fr (les certificats
avec joker sont évidemment les plus vulnérables à Drown puisqu'on les
achète justement pour les mettre sur plusieurs machines) :
% openssl s_client -connect 93.17.51.145:443 -ssl2
CONNECTED(00000003)
...
subject=/C=FR/postalCode=35000/ST=Ille-et-Vilaine/L=RENNES/street=10 rue Du Breil/street=ZI Rennes Sud-Est/O=SOCIETE OUEST FRANCE/OU=0002 377714654/CN=*.ouest-france.fr
...
SSL handshake has read 1609 bytes and written 367 bytes
---
New, SSLv2, Cipher is RC2-CBC-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv2
Cipher : RC2-CBC-MD5
Session-ID: 6F1500003AE7F4EF421B7C964089D28B
Le journal Ouest-France est hébergé par
SDV et
cette
93.17.51.145 est apparemment dans les
locaux du journal. Machine de développement ? Serveur utilisé pour des
applications internes ? En tout cas, contrairement au site Web public,
cette machine ne semble pas avoir fait l'objet de tests de sécurité
et, à elle seule, elle rendait l'attaque Drown possible.
En effet, il s'agit bien de la même clé (pas uniquement du même nom
dans le certificat) :
% openssl s_client -connect 93.17.51.145:443 | openssl x509 -pubkey -noout
...
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu83rhWk01bad5z55tfKN
TlqWSdXou/QXTNVsk0J47FFEYCvumcd5TgrLtsRDjz23K1+8T9KXgIzNN4wXwWUc
7O1Hu0ddX4w0OOiSaq2rxPcXdzeF98Mth+MtclUliYZTPa94TXEMSM/xPeELkfmi
sAqJjVFfGqacFcuzI0QryQPkAAU4ts0JtAoaUhHDNc+3Mz2UnHtaYsLEh9cHdkKq
QzpggPPN4emqcEr3fbvTPl0JIYossH/mOI8E4NTyVaZaScimi8efklxF3JEc+/6w
AqzGXt8CL2/ce+E4BojHCfilGrxU4WEeo7e9sMXHuhWCQ/fxT/6o3yktI+sLSv61
RQIDAQAB
-----END PUBLIC KEY-----
% openssl s_client -connect www.ouest-france.fr:443 | openssl x509 -pubkey -noout
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu83rhWk01bad5z55tfKN
TlqWSdXou/QXTNVsk0J47FFEYCvumcd5TgrLtsRDjz23K1+8T9KXgIzNN4wXwWUc
7O1Hu0ddX4w0OOiSaq2rxPcXdzeF98Mth+MtclUliYZTPa94TXEMSM/xPeELkfmi
sAqJjVFfGqacFcuzI0QryQPkAAU4ts0JtAoaUhHDNc+3Mz2UnHtaYsLEh9cHdkKq
QzpggPPN4emqcEr3fbvTPl0JIYossH/mOI8E4NTyVaZaScimi8efklxF3JEc+/6w
AqzGXt8CL2/ce+E4BojHCfilGrxU4WEeo7e9sMXHuhWCQ/fxT/6o3yktI+sLSv61
RQIDAQAB
-----END PUBLIC KEY-----
On trouvait d'ailleurs cette clé sur plein d'autres machines
du réseau
93.17.51.128/26, presque toutes
acceptant SSLv2 d'une façon ou d'une autre.
En revanche, si on regarde un autre domaine signalé sur le site
Web de Drown, blockchain.com, on voit que le
site Web public n'a pas du tout la même clé (ce n'est même pas le
même algorithme) que la machine vulnérable (alors que le nom dans
le certificat de la machine vulnérable est bien *.blockchain.com). Leur situation est
donc moins grave (attention toutefois aux attaques actives) :
# Machine vulnérable car acceptant SSLv2 dans certaines conditions
% openssl s_client -connect 50.87.196.92:443 | openssl x509 -pubkey -noout
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsXMk8xOJaaqKmz88RicY
Mt4e4VlY0uTVaUS7mbgnUGgd15wQ/tLH91RL5S9c1C1FFrcjBpomODJXBdgTXjWi
x4OVRl0sEe6OjIX1FLqBl15n+Lx++933lQUWinMSInEVLnBBjcr9If5+ozJvscRS
eF/hikjhDYW/rDwF1f7ivTiiok8f12zTa2lhlxOH4KxcFPaFklXDa45DccDjdCIZ
uVLpFSngo5iS3nney+LPK4afYYffEWK9aN2Rj9NE8zRm3hGoGDva2vNmKGbewd3w
1huqr3o7fc3WZyW9HZlM7PjZF6YLhgJnAI09XXDHD3t+G4ijcS6F4Rh9B36whuoo
CQIDAQAB
-----END PUBLIC KEY-----
# Serveur Web public
% openssl s_client -connect www.blockchain.com:443 | openssl x509 -pubkey -noout
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8DGz/3DLSflRPxO5uHuiww7EbqEP
/S3VWfdw4PGs4WcuqWTtIGht1rwiuTjrU3Es1uxm3T+JfT1JOOhYut8IjA==
-----END PUBLIC KEY-----
Pour résumer
ce point essentiel « Même si votre serveur n'accepte pas
SSLv2, vous êtes peut-être quand même vulnérable ».
(Au passage, petite note technique : certains
systèmes d'exploitation, et à juste titre,
compilent OpenSSL sans SSLv2. La commande ci-dessus vous dira
alors « unknown option -ssl2 ». Il faut
utiliser un système non sécurisé, comme Arch
Linux, ou bien prendre un OpenSSL qu'on a compilé
soi-même. C'est à cause de ce problème que l'excellent script
testssl.sh vient avec son
propre OpenSSL.)
On voit d'ailleurs un effet négatif de la
gamification
popularisée, dans le monde HTTPS, par SSLlabs. Pendant que
tout le monde s'amuse à obtenir la meilleure note possible pour
s'en vanter sur les rézosocios (« j'ai
un A sur SSLlabs alors que la banque Machin a uniquement un B, je
suis trop un geek crypto-expert »), des machines comme ce pauvre
serveur restent ignorés.
Autre question posée par Drown, pourquoi est-ce qu'il y a autant de
machines qui acceptent encore SSLv2 ? Il a été officiellement
abandonné en 2011 par le RFC 6176. Et le RFC est sorti bien tard, tous les experts
savaient depuis longtemps que SSLv2 était cassé sans espoir de
réparation. Mais les mises à jour ne se font, sur l'Internet, qu'à un
rythme glacial (voir nul). Le problème n'est pas technique, il vient
du fait que les mises à jour ne rapportent rien, n'ont pas de
retour sur investissement, et ne sont donc en
général jamais faites. Tout le monde s'indigne lorsqu'une faille comme
Drown est publiée mais, en temps normal, personne ne s'en
préoccupe. La prévention est toujours le parent pauvre de la
sécurité. L'opérationnel et la sécurité concrète n'intéressent personne.
Compte-tenu de cela, est-ce que Drown représente un réel danger
aujourd'hui, et faut-il patcher d'urgence ? Bien sûr, il faut patcher,
c'est le B. A. BA de la sécurité pour une machine connectée à
l'Internet. Mais le danger exact de Drown n'est pas facile à
évaluer. On est dans le cas classique en sécurité du verre que
l'optimiste voit à moitié plein alors que le pessimiste le voit à
moitié vide. L'optimiste va faire remarquer que l'exploitation
effective de Drown est très difficile, dans les conditions du monde
réel (en laboratoire, ça marche toujours mieux). Le pessimiste
rétorquera que les attaques ne vont toujours qu'en s'améliorant. Si
Drown est difficile à exploiter aujourd'hui, cela ne durera pas
éternellement. À noter que, pour la raison expliquée plus haut, cela
ne sert à rien de patcher votre serveur principal : il faut patcher
toutes les machines qui ont le certificat du
serveur principal.
Je suggère d'ailleurs d'en tirer une leçon : ne jamais partager un
certificat (et donc une clé privée) entre des machines qui ont des
administrateurs différents : le risque est en effet très élevé que
l'une d'elles soit moins sécurisée que les autres, permettant une attaque.
Ah, notez aussi que patcher OpenSSL ne
servira que pour le futur : si un attaquant a utilisé Drown contre
vous, et a réussi à obtenir des informations tels que vos mots de
passe, il serait prudent de les changer...
Merci à Léo pour avoir signalé une grosse approximation dans
l'article original.
