Je ne vais pas reprendre les détails de l'attaque qui sont très clairement expliqués sur le site monté par les sept chercheurs[1] en question ou plus simplement sur les slides de la présentation. De manière générale, l'attaque a consisté à créer une paire de certificats dont les parties sujettes à signature avait la même somme MD5. Une collision choisie en somme. Les bases théoriques permettant ce genre de choses remontent à 2004, et surtout aux améliorations notables qui ont ensuite été produite en 2006 puis en 2007 pour obtenir le résultat escompté.

Le point délicat de la technique est, une fois trouvée la paire de certificats qui va bien, dont un servira à usurper la CA, de se faire signer l'autre par une des autorités de certification[2] qui utilisent encore MD5 comme condensat pour leurs signatures. Ce qui veut dire en gros leur acheter un certificat serveur dont le contenu sera exactement celui attendu. Et c'est là que, parmi les six CA potentiellement attaquables, RapidSSL[3] entre en jeu. En effet, outre le fait qu'elle ait produit l'immense majorité de certificats signés en MD5 collectés par l'équipe, son système de génération de certificats présente une prédictibilité très appréciable :

  • les numéros de série des certificats sont incrémentés à chaque requête ;
  • il se passe exactement six secondes entre la demande de certificat et sa génération.

Ces deux aspects permettent alors de prédire facilement la période de validité, qui débute à la seconde près à la génération du certificat, et le numéro de série. Après plusieurs essais, ils vont obtenir de RapidSSL exactement le certificat serveur qu'ils attendaient, dûment signé, et qui possède la même somme MD5 que le faux certificat de CA précédemment préparé. Même somme MD5, donc même signature. Les voilà en possession d'un certificat d'autorité valide, parce que signé par la vraie CA de RapidSSL d'une part, et portant l'attribut de CA positionné en contrainte de base d'autre part...

C'est je pense ce qu'il faut retenir. Ils n'ont pas généré un faux certificat dont la signature était la même que celui de la véritable CA de RapidSSL, ce qui revient à trouver une seconde pré-image. Ils ont généré une collision soigneusement choisie entre deux certificats pour que l'un des deux ait l'attribut de CA et que l'autre puisse être généré et signé sur demande. Autant dire que cela demande du travail et des conditions favorables. Merci RapidSSL pour avoir réuni toutes ces conditions...


Les conséquences de tout ça ? C'est là qu'il faut être extrêmement prudent pour ne pas sauter du coq à l'âne. La conséquence d'une telle attaque pourrait être résumée de la façon suivante : elle permet de faire valider des certificats arbitraires par tous les systèmes qui font confiance à la CA de RapidSSL. Avec les conséquences qu'on imagine. Parce qu'au delà des considérations techniques précédemment évoquées, il s'agit avant tout d'un problème qui touche le moyen et l'objet principaux de toute PKI : l'organisation et la confiance.

Je m'explique. Quand on dit SSL, on pense immédiatement HTTPS. Et c'est bien naturel dans la mesure où il s'agit de la principale application utilisant ce protocole cryptographique. Du moins la plus visible et populaire. Ce n'est cependant la seule. Loin s'en faut. Mais je vais y revenir. L'aspect particulier de HTTPS et du système de distribution de confiance, que beaucoup qualifient de PKI, qui l'entoure, c'est qu'en tant qu'utilisateur, vous faites aveuglément confiance à un nombre particulièrement important de CA indépendantes les une des autres et pour la plupart commerciales. Pour vous donner une idée, le paquetage Debian ca-certificates contient pas moins de 140 certificats de CA. Ça fait pas mal de monde à qui votre navigateur, entre autres, fait confiance. Et parmi eux se trouve évidemment le fameux certificat RapidSSL. Et c'est bien là que le bât blesse. À partir du moment où vous lui faites confiance, c'est tout le système qui s'écroule puisque l'attaquant est non seulement capable d'usurper les certificats de tous les sites utilisant leurs certificats, mais également tous les autres ! Dans un scénario de type MitM par exemple, il suffira de générer à la volée un faux certificat signé par la CA factice et de fournir les deux en bundle au client. Et le tour est joué. C'est bête comme choux, l'attaque ne date pas d'hier et on sait faire depuis très longtemps...

Cependant, comme je le disais précédemment, HTTPS n'est pas la seule application qui repose sur SSL/TLS et/ou des certificats X.509. On pensera par exemple au courrier électronique, avec des protocoles comme IMAPS ou l'extension STARTTLS qu'on trouve principalement dans ESMTP, les nombreux mécanismes d'authentification basés sur X.509, typiquement quelques méthodes EAP comme PEAP ou EAP-TLS, ou encore tout ce qu'on appelle usuellement VPN SSL. Pour ne citer que ces quelques applications particulières. Dans l'absolu, toutes ces applications devraient être impactées par cette attaque, comme le précise le SANS. Sauf qu'elles ont quelque chose de particulier : elles n'ont pas besoin de faire confiance à plus d'une centaines d'organisations. En tout cas un nombre extrêmement limité d'entre elles. En fait, vous pouvez même n'accorder de confiance à personne d'autre que vous-même, en gérant votre propre CA interne, et ce que font la plupart des gens dans cette situation. Car à bien y réfléchir, votre client de courrier électronique n'a pas besoin de faire confiance à Verisign pour valider le certificat de votre serveur IMAP. Pas plus que votre supplicant 802.1x n'a à truster Thawte pour authentifier le serveur RADIUS de votre infrastructure Wi-Fi. Et même pour des applications comme S/MIME, la confiance à des CA indépendante, donc non maîtrisées, devrait être toute relative. Et on pourrait se prendre à rêver d'un client Web dont la liste de certificats racine serait drastiquement réduite, mais est-ce bien crédible ?

Tout ça pour dire qu'il y a pleins d'usages de SSL/TLS qui sont largement moins impactés que HTTPS par une telle attaque, quand elles y sont exposées. Typiquement, il est fort peu probable que les compères en questions puissent obtenir un certificat émis par une CA à usage privé. Et quand bien même ils le pourraient, je doute que le processus de génération satisfassent les conditions dont ils ont besoin pour mener l'attaque à bien, dans la mesure où il n'a, la plupart du temps, rien d'automatique. Comme je le disais plus tôt, loin de moi l'idée de minimiser la portée de ces travaux. Juste positionner le problème au bon endroit.


Maintenant, comment on corrige tout ça ? D'abord, quand on est CA, en n'utilisant pas MD5 pour signer des certificats. Passer à SHA-1 est un minimum, envisager mieux n'est certainement pas un luxe vu les récents développements autour des collisions sur cet algorithme. Le soucis, c'est que si SHA-1 est supporté par toutes les bibliothèques SSL, ce n'est pas le cas de SHA-2 ou des variantes longues de RIPEMD par exemple. Ensuite, en rendant un peu moins prédictible son mécanisme de génération. Enfin, en renouvelant les CA impactées et, par effet domino, tous les certificats générés par elles en cours de validité. C'est un boulot énorme, aucun doute là-dessus. Mais dans la mesure où personne ne sait si cette attaque n'a pas été réussie précédemment, on ne peut guère compter sur le fait qu'arrêter la génération de certificats faibles suffira à prévenir les conséquences à moyen terme de ce manque de clairvoyance. Côté administrateur de site, si vous dépendez de ces messieurs, il conviendra de demander au plus vite un nouveau certificat signé en SHA-1. Verisign s'est par exemple engagé à vous les renouveler gratuitement.

De mon côté, ça fait un petit moment que j'utilise un plugin pour Firefox appelé Perspectives, qui fournit une gestion des certificats à la SSH, en utilisant une base locale comme mémoire des certificats déjà vus et un réseau de notaires sollicitables au besoin. Le besoin initial pour ce genre d'extension était une meilleure validation des certificats auto-signés et autres CA personnelles. Et c'est pas mal, je vous le recommande, tout du moins vous invite à regarder de quoi il retourne. Ils fournissent aussi le service pour SSH avec un OpenSSH modifié et offrent une interface web.

Une autre mesure côté utilisateur serait de retirer les six CA de la liste de confiance. C'est un peu extrême, en particulier parce que cette mesure va empêcher vos applications d'authentifier les sites qui en dépendent. Pour autant, peut-on vraiment encore faire confiance à ces certificats ? Je vous laisse vous forger votre propre opinion.


Qu'est-ce qu'on doit retenir de tout ça ? Il y aurait pleins de choses à dire sur cette histoire. La réflexion qui me vient à l'esprit et que je crois avoir mentionné dans ces lignes, sinon à des nombreuses reprises oralement, est que la validation des certificats X.509 sur le web repose sur beaucoup d'acteurs commerciaux qui ne me semble pas suffisamment encadrés. Non pas que les acteurs commerciaux soient forcément plus mauvais que les autres, mais parce qu'ils ont des motivations et des impératifs qui rendent tentantes de petites entorses aux bonnes pratiques lorsqu'on ne les a pas à l'œil. Comme ne pas migrer son système de signature de MD5 à SHA-1. Par exemple. Ou à rogner sur les procédures de validation pour les renouvellements de certificat. Souvenez-vous de ce qu'en disait Pierre Vandevenne il y a déjà bien longtemps, à l'échelle d'Internet :

Les sociétés commerciales qui ne sont pas soumises à un
contrôle efficace sont fort tentées d'être incompétentes 
ou malhonnêtes.

On vient de voir un bel exemple d'incompétence. À défaut de malhonnêteté, encore que, voudriez-vous un joli exemple de mauvaise foi ? Pas de problème. Direction le blog de Tim Callan chez Verisign où on nous explique prestement de l'autorité de certification s'est définitivement débarassée de MD5. Mais aussi que ces méchants chercheurs ne les ont pas alerté alors que ce sont de gentils professionnels complètement dans la mouvance white-hat. Affirmation que critique Robert Graham certes violemment, mais avec des arguments on ne peut plus valide. Là où ça laisse perplexe, c'est quand on apprend qu'en fait, Verisign avait bel et bien été mis au courant du contenu de la présentation et de ses implications dès le 23 décembre, par l'intermédiaire de Microsoft, mais il semble que l'information se soit perdue dans les méandres de la hiérarchie. La mauvaise foi s'arrêterait-elle où commence l'incompétence ?...

La question est donc de savoir à qui on peut faire confiance, et pourquoi faire exactement. SSL est basé sur un modèle de confiance qui à certes bien des défauts, mais qui, bien utilisé, peut se révéler très efficace. Dans ce "bien utilisé", il y a en particulier une étape de vérification. Car la confiance ne tombe pas du ciel : elle se mérite. Exactement comme l'explique Richard Thieme pour un tout autre sujet :

Trust, but verify...

Notes

[1] À savoir Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik et Benne de Weger.

[2] Plus couramment appelées CA, pour Certification Authorities.

[3] Filiale de Verisign depuis le rachat de GeoTrust fin 2006.