* Your App shouldn’t suffer SSL’s problems.

– Date : 06 Decembre 2011

– Gravité : Elevée

– Description : Comme le rappel le chercheur Moxie Marlinspike, connu pour ses nombreux travaux sur la sécurité fournie par SSL, SSL est souvent utilisé à mauvais escient.

En effet, le modèle sur lequel repose SSL, avec son grand nombre d’autorités de certification incluses par défaut dans bon nombre de trousseaux de clefs de logiciels, est fait pour valider les identités d’entités non définies, qu’un développeur ne connait pas lorsqu’il développe son logiciel. C’est par exemple le cas des éditeurs de navigateur web, qui ne sont pas en mesure de connaitre au préalable la liste exacte des sites sur lesquels vont naviguer les internautes.

Cependant, ce modèle n’est pas valable pour l’ensemble des applications. Par exemple, dans le domaine des applications mobile, il n’est pas rare qu’une application fasse appel à des ressources hébergées sur le serveur de la société éditrice. On pense aux nombreuses applications de présentation de contenu, telles qu’iCERT-XMCO, qui ne font que récupérer des données "fraiches" sur un serveur contrôlé par l’éditeur de l’application afin de les présenter à l’utilisateur. Dans ce type de situation, le serveur utilisé et donc son identité sont connus par l’application. Il est donc tout à fait envisageable de se passer d’une majorité des clefs contenues dans le trousseau proposé par le système d’exploitation, voire de se passer de ce dernier dans son intégralité, afin de ne pas reposer sur l’écosystème des autorités de certification pour valider l’identité du serveur utilisé. En effet, l’actualité de l’année 2011 l’a clairement mis en avant avec les affaires Comodo, Diginotar, ou encore DigiCert Sdn. Bhd. Le niveau de confiance trop important mis de façon aveugle au sein de ces sociétés pose de nombreux problèmes lorsque l’une d’entre elles est victime d’une attaque.

Pour contrer ce risque, le chercheur met en avant une pratique alternative. Il s’agit du "Certificat Pinning". Cette solution n’est pas nouvelle, puisque Google l’utilise déjà au sein de son navigateur Chrome pour valider les certificats utilisés sur ses nombreux sites. Pour cela, Google a simplement ajouté au sein de son navigateur les identifiants de ses certificats. À chaque connexion protégée par SSL vers l’un des serveurs de Google, le navigateur vérifie la validité du certificat présenté par le serveur auprès de cette liste d’identifiants. Si le certificat ne correspond pas à cette liste prédéfinie, c’est alors qu’il s’agit très probablement d’une attaque de type "Man-In-The-Middle", étant donné que le pirate ne peut pas utiliser le même certificat que celui utilisé par Google.

Deux alternatives existent pour mettre en place ce type de solution technique : le développeur décide de se passer totalement du trousseau de clefs qui contient l’ensemble des certificats SSL Racine des autorités de certification. Auquel cas, il devra mettre en place sa propre "autorité de certification", embarquer le certificat racine de celle-ci au sein de son application, et valider le certificat présenté par le serveur à l’aide de ce certificat racine et de l’identifiant de certificat défini au sein de l’application. La seconde solution consiste à faire comme Google : valider l’identifiant du certificat présenté par le serveur à l’aide de la liste d’identifiants embarquée dans le logiciel, en se reposant sur le certificat racine de l’autorité de certification pour l’étape de validation.

D’un point de vue théorique, la première solution permet de s’affranchir complètement des problèmes de sécurité liés à l’ensemble des autorités de certification, alors que la seconde ne permet que de restreindre ce problème de sécurité à la seule autorité de certification ayant émis le certificat du serveur. Certaines attaques restent donc possibles, si l’autorité signe par exemple des certificats avec des clefs publiques dites "faibles".

Cette technique de "pinning" n’est pourtant pas optimale, ni adaptable à toutes les situations. En effet, il n’est pas envisageable d’épingler l’ensemble des certificats utilisés sur Internet au sein des différents navigateurs : trop de certificats peuvent changer très régulièrement... Bref, cette solution n’est pas "scalable".

– Référence :

http://blog.thoughtcrime.org/authenticity-is-broken-in-ssl-but-your-app-ha

– Lien extranet XMCO :

https://cert.xmco.fr/veille/client/index.xmco?nv=CXA-2011-2109