« 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é.

[...]

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 le certificat du site visé (et donc la clé privée) 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 [...] Mais on trouve, sur un tout autre réseau, une machine 93.17.51.145 qui, elle, accepte SSLv2 et a le 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) [...] 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 rend l'attaque Drown possible.

[...]

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.

[...]

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.

[...]

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. »