SSL est cassé

(Notez que j'ai soigneusement évité "l'échec de SSL" comme titre, mais je n'en pense pas moins :)

Ce dont je ne vais pas parler

• Si vous êtes un tant soit peu versés dans la technique, vous avez probablement entendu parler de la factorisation d'une clé RSA-768 par l'INRIA.

La puissance de calcul mise en œuvre pour cette "prouesse" laisse penser que la NSA sait faire la même chose en une semaine (sans parler de notre machine TERA, bien française).

Accessoirement, il est amusant de constater que des clés 768 bits sont utilisées par les cartes EMV en remplacement de la clé 320 bits qui a été factorisée par Serge Humpich …

… mais RSA-1024 reste aujourd'hui impossible à factoriser par le grand public.

• Vous avez également entendu parler de SSLStrip, par Moxie Marlinspike.

Une attaque man-in-the-middle "basique" qui réécrit les liens HTTPS en HTTP. Très efficace contre les moldus de l'informatique … mais qui n'affecte pas les outils automatiques (bien configurés) ou les geeks qui ont mis tous les sites critiques en "HTTPS forcé" dans NoScript (ou qui utilisent des add-ons dédiés).

• Vous avez entendu parler de l'attaque d'Alexander Sotirov, ayant exploité les faiblesses de MD5 pour générer une "vraie-fausse" autorité de certification parfaitement valide et largement reconnue ?

Beau travail … mais la plupart des implémentations ont blacklisté ce certificat.

• Vous avez entendu parler de l'attaque en renégociation, qui permet d'injecter des données en aveugle au début d'une session TLS ?

Désolé … mais là encore c'est patché presque partout.

• Vous êtes assez vieux pour avoir entendu parler de la faille OpenSSL exploitée par le ver Slapper en 2002 ?

C'est patché partout … ou presque (n'est-ce pas PolyCom ? ;).

• Vous avez entendu parler d'un "petit problème" d'entropie dans Debian ?

Rassurez-vous, ça devrait normalement être patché (presque) partout …

• Vous utilisez GnuTLS ?

Bon là c'est sans espoir, désolé !

Bref, vous êtes un technicien. Mais saviez-vous que le modèle SSL est fondamentalement cassé ?

La faille dans SSL

SSL, un protocole conçu par Netscape pour le e-commerce, est là pour assurer la confiance.

Pour faire simple, il existe deux modèles de confiance en informatique: le modèle "pair à pair", utilisé par GPG, et le modèle "à site central", utilisé par SSL.

Dans le premier modèle, vous faites confiance à un inconnu parce que vous l'avez rencontré au moins une fois, ou quelqu'un que vous connaissez l'a rencontré au moins une fois. C'est relativement fiable (quoique l'expérience des réseaux sociaux montre qu'on a tendance à faire confiance un peu trop vite), mais ça passe difficilement à l'échelle.

Dans le deuxième modèle, vous faites confiance à un inconnu parce qu'il existe une autorité d'enregistrement mondiale qui a "vérifié" tous les inconnus. Ca passe très bien à l'échelle, mais ça suppose une confiance inébranlable dans l'autorité "racine". Or c'est là que le bât blesse.

Car l'autorité ne gagne pas d'argent (oui, accessoirement, c'est une activité lucrative) à chaque fois que vous désirez vérifier l'identité d'un inconnu. L'autorité gagne de l'argent à chaque fois qu'elle enregistre un nouvel inconnu. Et donc son business model est d'enregistrer un maximum d'inconnus le plus rapidement possible, en minimisant les vérifications.

Ceci étant posé, quelles sont alors les véritables attaques contre SSL ?

• Les "fusions acquisitions"

Et oui, la vie est dure, et vendre de la confiance ne rapporte pas suffisamment d'argent. Il y a donc des autorités racines qui ont duré moins longtemps que leur certificat (soit 20 ou 30 ans) et qui ont été rachetées.

C'est ainsi qu'on a pu voir sur la liste des développeurs Mozilla une discussion intéressante autour de la question "qui possède la racine RSA Security 1024 V3 ?".

Tout est bien qui finit bien, puisque la racine en question appartenait bien à la société RSA, qui avait simplement arrêté de maintenir les points de contact identifiés dans la CA. Et qui a donné son feu vert pour supprimer purement et simplement cette CA de la liste des autorités racine de confiance.

Aucune autorité "majeure" n'a complètement disparu à ma connaissance, mais je n'exclus pas que le HSM d'une autorité racine puisse se retrouver un jour en vente sur eBay …

• La sous-traitance

Pour vendre partout, il faut passer par des partenaires locaux. Par exemple en France, Gandi revend des certificats signés par "UTN – DATACorp", c'est-à-dire Comodo.

Les partenaires n'adhèrent pas forcément avec zèle à la DPC du fournisseur. C'est ainsi qu'un "vrai-faux" certificat Mozilla a pu être obtenu sans aucune vérification auprès d'un sous-traitant de Comodo.

Pourtant d'un point de vue technique, la "confiance" est binaire: soit le navigateur accepte le certificat, soit il le rejette. Il n'y a pas de score attaché au sous-traitant qui a délivré le certificat …

• La prolifération des autorités racines

Entendons nous bien: je parle ici des "vraies" autorités, celles qui paient pour être intégrées à Windows ou aux navigateurs.

Le débat a enflammé la liste de discussions des développeurs Mozilla: faut-il intégrer une autorité de certification chinoise par défaut dans le navigateur ?

Sans rentrer dans le débat politique, on notera qu'il existe déjà plein d'autorités nationales. Comme une autorité hongroise, dont la DPC n'a pas été traduite dans d'autres langues que le hongrois. Difficile de construire la confiance la dessus ...

• L'appât du gain

Je ne parlerai pas de la supercherie qu'est EV-SSL, c'est-à-dire une tentative pour mettre fin à ces dérives sur le principe du "plus les gens paient cher, plus on peut leur faire confiance". Ou, pour le dire autrement, "les gens les plus riches sont forcément les plus honnêtes" …

Non, la dérive dont je veux parler, c'est la délivrance de certificats gratuits, mais à courte durée de vie. C'est évidemment un abus de confiance: s'il est possible d'obtenir chez VeriSign un certificat de signature d'une durée de vie de 60 jours sans présenter aucun justificatif, alors cela permet de compromettre l'iPhone, mais également de signer un exécutable ou une macro Office pour une attaque "one shot".

• L'interception légale

Last but not least, il faut noter que les équipements d'interception légale pratiquent le spoofing SSL sans problème. Comment ? Tout simplement avec la coopération de quelques autorités racine nationales, qui délivrent les certificats ad-hoc. Vous pourrez lire le papier ici, ou le compte-rendu dans la presse.

Y a-t-il une solution ?

Pour être honnête, je ne pense pas qu'une solution puisse venir du "marché". Car si la confiance a un prix, alors il y aura toujours quelqu'un pour payer. Après tout la mafia russe a bien monté son propre FAI, pourquoi n'aurait-elle pas sa propre autorité de certification ?

La solution technique théorique au problème est la révocation. Mais ça ne marche pas du tout. Par exemple la sécurité du système Symbian 9 est basée sur ce mécanisme, mais les opérateurs de téléphonie mobile ne l'activent pas (pour des raisons essentiellement économiques).

Et quand VeriSign a délivré un "vrai-faux" certificat Microsoft, il a bien fallu pousser une liste de révocation "en dur" par Windows Update, car aucun client ne vérifiait correctement les révocations.

En attendant, les geeks peuvent toujours utiliser des extensions comme "Perspectives" ou "Certificate Patrol". Ca peut toujours servir ;)

Ma conclusion est simple: le modèle de sécurité des autorités de certification ne vous protège que contre les attaques passives (écoute d'une connexion SSL). Mais pas contre les attaques actives (man-in-the-middle SSL, authentification par certificat client, signature de code, etc.). Et ça n'est pas prêt de changer.