Lorsqu’un utilisateur se connecte à un site internet via le protocole chiffré HTTPS, c’est le protocole SSL (Secure Socket Layer) qui se charge du chiffrement. Pour ce faire, des mécanismes de cryptographie asymétrique sont employés pour valider le certificat du serveur et negocier la clé de cryptage qui cryptera les données.
Le navigateur web de l’utilisateur va tenter de vérifier l’identité du serveur auquel il se connecte. Pour cela, le serveur présente au navigateur un certificat X.509, contenant notamment sa clé publique et une signature. Le navigateur va alors vérifier la validité de la signature, puis utiliser la clé publique afin d’échanger une clé de session qui sera utilisée pour chiffrer l’ensemble des communications de manière symétrique.
Le navigateur vérifie ensuite la validité de la signature en s’assurant de l’existence d’une chaîne de confiance (chain of trust) entre le certificat et l’une des autorités de certification de confiance. Qui sont ces autorités de confiance ? C’est en tentant de répondre à cette question que l’on réalise la fragilité du système actuel.
Pour que le navigateur accepte la connexion, il va remonter la chaîne de confiance jusqu’à l’autorité de confiance racine et s’assurer que celle-ci est présente dans le magasin de certificats.
Le navigateur Firefox, par exemple, dispose de son propre magasin de certificats auxquels il fait confiance. D’autres, comme Internet Explorer ou Chrome, se basent sur le magasin de certificats du système d’exploitation.
Et par défaut, ces magasins regorgent d’autorités de certification, de tous pays ! Le navigateur Firefox en compte plus d’une centaine.
Il suffit donc qu’une seule de ces autorités de certification délivre, par erreur ou plus vraisemblablement suite à une attaque, un certificat valide pour “*.google.com” pour que des attaquants puissent mener une attaque de type Man-in-the-Middle. En se faisant passer pour un serveur légitime de Google, ils pourront intercepter et déchiffrer les échanges entre le navigateur et le serveur.
Afin de se prémunir des deux scénarios envisagés, il est possible d’utiliser le protocole SSL d’une autre façon, en créant une association entre le nom de domaine d’un site (www.google.com) et le certificat ou l’autorité de certification attendus. Ainsi, seul le certificat attendu ou un certificat signé par l’une des autorités de certification attendues sera accepté et une alerte sera levée si un autre est présenté.
