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.
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.
- 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 ?
- 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 ?
- Vous êtes assez vieux pour avoir entendu parler de la faille OpenSSL exploitée par le ver Slapper en 2002 ?
- Vous avez entendu parler d'un "petit problème" d'entropie dans Debian ?
- Vous utilisez GnuTLS ?
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"
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
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
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
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
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.
14 commentaires:
Ce qui veut dire que OpenVPN est aussi dans ce cas alors, non?
Je m'interrogeais dernièrement aussi sur SSL/TLS: "Fiable ou faible?" (pour éviter le mot FAIL galvaudé jusqu'a la corde).
Je pense que la critique de SSL repose surtout sur sa dualité:
On chiffre la communication ET on authentifie l'autre extrémité.
Pour le côté chiffrement, cela fonctionne bien (tout du moins, pas trop mal). Pour l'authentification, eh bien, je redonne l'apophtegme rappelé par Sid:
"Trust but Verify"
De ceci découle immédiatement la question: est il possible de vérifier de manière automatique (informatique) l'identité distante de façon fiable? Ce serait un beau sujet d'étude :) Le mécanisme des CA ne reposant que sur la confiance, quel crédit lui accorder lorsque cette confiance n'est plus?
A part ça, je croyais le blog mort ;)
Très bonne analyse ! Merci à toi pour ce billet très clair et qui présente la faille là où on n'y pense pas toujours ;)
Très bonne synthèse :)
Une petite remarque toutefois concernant les cartes EMV : les clés utilisées actuellement font 1152 bits, et les précédentes faisaient 1024 bits. Les clés 768 bits étaient utilisées dans les cartes B0', norme ayant précédé EMV.
@Frédéric Reynier: pour OpenVPN, tout dépend de sa configuration ! Mais normalement, OpenVPN ne fait confiance qu'aux autorités explicitement spécifiées dans la configuration (et pas la base de confiance du système).
@Kevin: non, le blog n'est pas mort ... C'est juste que blogger intelligemment prend énormément de temps ! C'est d'ailleurs pour cela que tout le monde Twitte désormais ;)
@Anonyme: merci pour les corrections.
Tout d'abord je salue le courage d'écrire un article aussi long, avec autant de références, et qui a l'interet d'attirer l'attention sur un problème réel.
Maintenant avec un titre aussi provocateur je me sens obligé de réagir avec quelques critiques constructives :)
1. Le terme "SSL" est utilisé dans votre article pour désigner des choses différentes entre elles et de ce qu'est vraiment SSL. Vous parlez principalement de certificats dans le cadre de la navigation sur Internet, donc plus de PKIs que de SSL proprement dit (où l'utilisation de certificats est optionnelle).
2. Je trouve que vous faites (a dessein ?) la confusion entre une technologie (PKI) et une application particulière (la navigation sur Internet). Les PKIs (tout comme SSL/TLS d'ailleurs) sont utilisés dans d'autres contextes que la navigation sur Internet, et ils y fonctionnent trés bien.
3. Affirmer que SSL ne protège pas contre contre les MiTM (alors que c'est précisément un de ses buts) parce que la mafia russe pourrait obtenir un certificat n'est pas trés sérieux. L'acceptation ou le refus du certificat présenté dépend de l'utilisateur, pas de SSL. Et si votre Firefox fait confiance à 250 certificats ou si la société XYZ délivre des certificats trop facilement, la faute n'en incombe pas à SSL.
4. Outre les extensions que vous citez, Firefox peut aussi etre configuré pour vérifier par défaut les révocations via OCSP. Peut-etre qu' "aucun client ne vérifiait correctement les révocations" en 2001 (date de votre lien), mais aujourd'hui ça fonctionne mieux.
@sam280: merci pour ce commentaire pertinent et constructif.
Oui, je mélange et je confonds allègrement SSL et PKI. Mais dans l'esprit des gens, c'est la même chose. "Cadenas jaune == je peux payer avec ma CB sur Internet".
Bien sûr, je suis d'accord avec vous dans le fond sur le fait que toutes les failles d'implémentation relevées ne mettent nullement en cause la qualité cryptographique du protocole TLS actuel, tout comme AES n'est nullement responsable du fait que la majorité des gens choisissent "123456" comme mot de passe.
Je suis également d'accord sur le fait que des PKI internes ont pu être déployées avec succès dans des entreprises, et ceux pour d'autres usages que SSL (tels que S/MIME ou l'authentification forte).
Je suis moins d'accord pour dire qu'il est normal que tous les navigateurs fassent confiance par défaut à 250+ autorités racine, mais que le man-in-the-middle reste impossible. Surtout quand on voit que les autorités en question sont utilisées par différents gouvernements à des fins d'interception légale.
Et cette faiblesse ne concerne pas que les navigateurs: sous Windows, tous les produits basés sur la CryptoAPI vont faire confiance au magasin de certificats local. Ou comment se retrouver avec une passerelle VPN qui accepte les certificats émis par un éditeur antivirus dont le produit est installé sur la même machine ...
Il est amusant de penser que le "Trusted Computing Group" envisageait initialement une autorité racine mondiale unique pour l'initialisation des puces TPM :)
Quant à OCSP ... j'attends de voir des implémentations qui fonctionnent (chez les tiers de confiance) et des clients qui l'activent par défaut ! (cf. problème des virus signés sous Symbian 9)
La révocation reste de toute façon un acte commercial plus que technique. S'il est possible de révoquer un certificat clairement identifié comme volé ou utilisé frauduleusement (une fois identifié comme tel !), il n'a pas été question de révoquer tous les certificats délivrés par des autorités utilisant encore la signature MD5, malgré la publication d'un vrai-faux certificat par Alex Sotirov. Pourtant n'importe qui aurait pu réaliser silencieusement la même attaque: la sécurité des clients aurait voulu qu'on applique le "principe de précaution".
On peut supposer également que les certificats délivrés par une autorité ayant fait faillite ne seront jamais révoqués.
Et si chaque virus actuel était signé avec un certificat différent (cf. certificats temporaires délivrés par VeriSign), les listes de révocation exploseraient autant que les bases de signatures antivirus !
Bref, le débat est loin d'être clos :)
on trouve le même argumentaire, peut-être un peu plus détaillé mais sans les rappels d'actualité dans http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
Bonsoir,
Pour préciser ma pensée, je ne trouve pas non plus normal que les navigateurs soient livrés avec un si grand nombre de certificats, ou même la façon dont Microsoft peut ajouter arbitrairement des certificats sous Windows 7 (voir http://is.gd/bIXnK). Le sens de ma phrase était simplement de dire que la responsabilité du problème s'étendait au delà de SSL, par exemple aux éditeurs de navigateurs et de systèmes d'exploitation.
Pour en finir avec OCSP, il est activé par défaut sur Firefox 3.x (voir about->config / security.OCSP.enabled) et il marche correctement d'après les quelques tests que j'ai effectués :)
@sam280: une PKI n'est pas une technologie, c'est un process qui s'appuie sur des outils ma foi assez classiques, voire anciens (OpenSSL ne date pas d'hier par exemple). Ça aussi, c'est une confusion courante qui mériterait un long billet à elle toute seule...
Le vieux maître Bruce Schneier se tourna alors vers le jeune scarabée et lui murmura d'un air pénétré "Security is a process, not a product..."
Voila bien une chose qui m'amuse: quand un non-technicien utilise par erreur "certificat" à la place de "clé privée", je vois souvent un technicien le corriger d'un ton sec pour son manque de précision. En revanche les mêmes techniciens utilisent sans complexe en français le mot anglais "process" comme un fourre-tout pour tout ce qui n'est pas hardware ou software.
En l'occurrence je ne sais pas ce que vous entendez par "process", mais un PKI n'est certainement pas un "process" au sens des définitions généralement utilisées (PMI, ITIL, PRINCE2). En revanche un PKI s'appuie sur _des_ "process", par exemple pour la gestion des étapes du cycle de vie d'un certificat. De même qu'il s'appuie sur des technologies sans en être une, comme je l'ai écrit trop rapidement. Quant aux outils, je pense les connaitre assez bien pour déployer et auditer des PKI de temps en temps, merci.
Comme ca vient juste de tomber, je complète ton excellente analyse :
VeriSign a revendu toute sa partie SSL à Symantec, et moi avec...
La raison : c'est exactement ce que tu expliques. De plus en plus de compagnies vendent des certificats SSL très bons marchés, alors VeriSign a décidé que c'était plus un marché intéressant pour eux.
Je ne parle même pas de la facilité et de la confiance qu'on peut, encore, avoir dans ce fameux "trust".
s/VeriSign/Symantec
http://www.symantec.com/business/theme.jsp?themeid=vs
Comme quoi tout va très vite, Symantec a déjà récupéré le logo de VeriSign, mais en jaune cette fois-ci ;)
http://my.opera.com/securitygroup/blog/2010/06/02/how-secure-is-the-secure-web-ssl-tls-server-stats-part-2
Merci pour ce post tout à fait explicite qui m'a permis de comprendre ce sujet qui me paraissait bien "barbare" au premier abord ...
Enregistrer un commentaire