Stéphane Bortzmeyer nous a parlé du bon usage de TLS dans sa présentation intitulée « Utiliser TLS sans se tromper ».

Voilà un résumé de ce que nous avons compris de cet excellent talk.

Pitch

Le protocole de cryptographie TLS (ex-SSL) permet de s’assurer de l’authenticité de la machine à laquelle on se connecte (en HTTP, ou bien avec un autre protocole). Mais son utilisation correcte depuis un programme n’est pas facile, comme l’a montré le fameux article « The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software ». On va donc parler de ce que TLS garantit… et de ce qu’il ne garantit pas.

TLS, qu’est-ce que c’est ?

TLS est par exemple connu pour être la technologie derrière HTTPS, SMTPS, … TLS permet de faire transiter des données en toute confidentialité. Comment ça marche ? En voici les grandes étapes (simplifiées) : Récupération du certificat de la ressource sécurisée ; Vérification que le certificat est bien signé par une autorité de confiance ; Enfin l’échange sécurisé peut commencer.

TLS, cas nominal

TLS, entre sécurité et illusion

Avant de commencer à parler des rouages de TLS, Stéphane nous a rappelé quelques principes importants : Faire circuler des données chiffrées est inutile si une des machines comprises dans l’échange est compromise (que ce soit le serveur ou le client) ; On oublie parfois la présence d’intermédiaire. Exemple : Que dire de la confidentialité d’un mail écrit sur un serveur GMail, même sécurisé ?

De manière plus générale, il est crucial de se rappeler que TLS ne protège que du transit d’un message, et non pas de ce qu’il se produit aux extrémités.

TLS, dans la vraie vie

Une fois tout ça en tête, on l’aura compris, cela ne peut fonctionner que si l’étape d’authentification est assurée. Cela empêchera une attaque de type "Homme du milieu" (ou Man In The Middle en anglais), comme le montre le schéma ci-dessous :

TLS, avec un faux certificat

Authentifier d’accord, mais comment ? Plusieurs techniques existent en réalité, mais dans la pratique, la plus utilisée reste la norme RFC 2459 (qui décrit le standard X.509). Dans cette norme, tout repose sur ce qu’on appelle la « chaîne de confiance », dont le point de départ sont les autorités de certification.

Les autorités de certification sont les organismes qui délivrent les certificats pour l’ensemble des sites web de la planète. Le système du client (OS, navigateur, …) contient le certificat auto-signé de chaque autorité. Les certificats des sites web sont signés (directement ou non) par la clé privée associée au certificat racine de l’autorité. Ce sont ces certificats stockés dans le système qui permettront par la suite la vérification des certificats fournis par des sites web tiers.

On comprend donc que dans ce système existe un "single point of failure" constitué par les autorités de certification. Si une de ces autorités est corrompue, il devient possible de générer un certificat pour n’importe quel site web et donc d’usurper son identité. Cela n’est pas simplement une fiction et est déjà arrivé par le passé avec l’autorité de certification DigiNotar en 2011 et qui a permis au(x) pirate(s) exploitant la faille de générer n’importe quel certificat (y compris GMail, vos paiements en ligne, vos comptes en banques, etc).

Et quand bien même aucun piratage n’aurait lieu, peut-on vraiment avoir confiance en l’impartialité et l’arbitrage de l’armée turque qui possède une autorité de confiance ?

TLS, implémenté

Stéphane nous a ensuite rappelé que les bibliothèques qui implémentent TLS ne sont pas nécessairement sans bugs.

Parmi les plus connues, nous trouvons la fameuse, et depuis quelques jours tristement célèbre, OpenSSL. OpenSSL est l’implémentation utilisée par le monde entier, y compris de très importantes entreprises qui ont de très gros enjeux de sécurité. C’est aussi une bibliothèque qui a un des budgets annuels les plus bas, même si cela commence à changer.

Oui, nous parlons bien d’une des pierres angulaires de la sécurité moderne.

En conséquence, nous trouvons des failles du type Goto Fail, Heartbleed, Timing attack, …

TLS, utilisé

Un certain nombre de technologies utilisent TLS. Certaines sont sécurisées par défaut, d’autres non. Par exemple, urllib2, librairie standard de Python pour travailler en http/https, ne valide pas les certificats lors de la connexion vers un site en https. Parmi les défauts rencontrés dans les bibliothèques, on trouve aussi des documentations trop pauvres ou une programmation trop bas niveau.

Mais la cause principale de risques reste certainement les "débrayeurs", comme les appelle Stéphane, qui sont ces développeurs qui baissent délibérément le niveau de sécurité pendant les développements, en prenant en même temps le risque d’oublier de réactiver la sécurité une fois en production.

Ce sont aussi pendant les développements qu’on teste qu’on arrive bien à utiliser TLS avec notre application. Mais il est aussi important de tester les cas non-passant, c’est à dire que la connexion à un site échoue si son certificat est invalide.

TLS, sans se tromper

En conclusion, voici comment Stéphane nous propose d’utiliser TLS, sans se tromper : Les communautés derrière les technologies web doivent sans cesse s’efforcer de produire de meilleures API (comprendre facile à utiliser) et, surtout, dans le bon sens (secured first) ; Les développeurs utilisant les bibliothèques doivent faire l’effort de bien lire la documentation des API ; Des tests, plus de tests, sans oublier les cas non-passants ; la meilleure manière de sécuriser des données, c’est de ne pas les collecter.