Certificate Pinning

novembre 10, 2014  |   Actualités,Blog   |     |   0 commentaire

Introduction

Grâce à l’augmentation des performances des équipements Web (aussi bien clients que serveurs) et à la recrudescence des interceptions de flux réseau, le chiffrement est de plus en plus utilisé afin de sécuriser les échanges. Ces échanges sont dans la majorité des cas chiffrés grâce aux protocoles SSL/TLS qui reposent sur des certificats X.509 pour la partie authentification.

Nous allons détailler dans cet article comment fonctionne la chaine de certification, les risques inhérent à une usurpation de certificat et les méthodes pour s’en protéger.

Principe de certification

Lors de l’établissement d’un flux utilisant un certificat X.509, le serveur fourni le certificat permettant d’authentifier son identité (par exemple: randco.fr).

Ce certificat sera émis par un “tiers de confiance” tel que Verisign, Gandi (dans notre exemple), Thawte ou même une autorité de certification locale. Cette autorité, attestera alors que le certificat du site “randco.fr” a bien été emis par elle et qu’il n’a pas été révoqué (via la publication d’une Certification Revocation List (CRL) ou d’un service OCSP).

Usertrust randco.frToutefois, afin de pouvoir faire confiance à cette autorité, il faut qu’elle soit elle même authentifiée. Afin d’y parvenir, tous les clients  prenant en charge TLS (navigateurs Web notamment), dispose d’une liste de Certificats Racines (Root Certificate). Ces certificats sont alors considérés comme surs par l’éditeur de votre navigateur. Il suffira donc que dans la chaine de certification du site “randco.fr” il y ait une autorité de certification attestant de la légitimité des autorités de certification intermédiaires (ici USERTrust attestant que Gandi est légitime).

Usurpation

Si un utilisateur malveillant parvient à obtenir un certificat frauduleux (par exemple *.monsite.fr) auprès d’une Autorité de Certification (Certificate Authority), alors il pourra certifier que tous les sites publiés tels que foo.monsite.fr, bar.monsite.fr ainsi que www.monsite.fr sont légitimes. Cet utilisateur pourra de ce fait effectuer une attaque Man In The Middle et intercepter toutes les communications chiffrées sans aucune alerte de sécurité.

Cette attaque [5] a pu être effectuée le 10 Juillet 2011 sur l’autorité de certification DigiNotar auprès des services Google grâce à l’émission frauduleuse du certificat *.google.com.

L’attaquant à pu effectuer un MITM en Iran pendant plusieurs jours.

Plus tard, DigiNotar admettra que des douzaines de certificats ont été émis couvrant les domaines de Yahoo, WordPress, Mozilla, Tor Project, …

Diginotar - Firefox 4

La compromission à été corrigée en supprimant le certificat de DigiNotar du magasin de certificats des navigateur, obligeant la mise à jour massive des navigateurs Web afin de ne plus être vulnérable.

Certificate Pinning

Afin d’éviter qu’une telle attaque se reproduise, il est possible d’utiliser le Certificat Pinning.

Le schéma ci-dessous explique le fonctionnement standard de l’authentification par TLS lors de l’accès d’un client au site de sa banque.

 

Chaine de certification “standard”Lors d’une attaque, de type HTTPS Interception, l’attaquant fourni un certificat au client couvrant le nom du site visé. Dans notre exemple ci-dessous, l’AC3 est compromise et le pirate arrive à lui faire signer un certificat attestant de la légitimité de “www.mabanque.fr”.

Site sous attaque de type Interception HTTPSDans le cas où le client utilise le Certificate Pinning, il vérifie en plus que le certificat fourni par le pair TLS (le proxy pirate dans le cas de l’attaque) est conforme à celui de l’éditeur de l’application (celui fourni par “www.mabanque.fr”).

De cette façon, le client ne serait pas tombé sous le coup d’une attaque sans aucune alerte de sécurité

Cette méthode pose cependant de nouveaux problèmes :

1 – Comment gérer le changement de certificat

2 – Comment intégrer l’intégralité des certificats ou des signatures au sein des navigateurs.

Pour le premier problème, il ne peut être géré que par une mise à jour (soit de l’application entière, soit du certificat uniquement). Il faudra toutefois s’assurer de la provenance de la mise a jour pour ne pas retomber sous le coup d’une attaque.

Concernant le second, il est évident qu’il n’est pas possible d’intégrer tous les certificats du monde dans un navigateur. C’est pourquoi cette solution est plus adaptée aux applications spécifiques (clients lourds tels que Dropbox, Spotify, …) qui de fait pourront intégrer le certificat authentique. En effet, ces applications sont couramment et facilement mises à jour, il sera alors facile de modifier le certificat si nécessaire. C’est également le cas de  Google Chrome qui contient dans son magasin l’ensemble des certificats nécessaires au fonctionnement de Google et ses applications (Drive, Gmail, Agenda, …) et protège donc ses utilisateurs d’une usurpation sur son propre périmètre.

Conclusion

Le chiffrement des échanges est de plus en plus utilisé. Cependant, nous venons de voir que cette protection peut être inefficace si le certificat n’est pas scrupuleusement vérifié.

Le Certificate Pinning permet de répondre à cette problématique mais en apporte de nouvelles avec lui. Pour les éditeurs, il convient d’évaluer avec précaution où et comment l’implémenter.

Bibliographie

[1] https://viaforensics.com/resources/reports/best-practices-ios-android-secure-mobile-development/41-certificate-pinning/

[2] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

[3] http://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning

[4] http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates

[5] http://magazine.qualys.fr/menaces-alertes/diginotar-attaque-certificats/