[DevoxxFR 2014] Utiliser TLS sans se tromper – Une conférence animée par Stéphane Bortzmeyer.

Bon, et bien voilà, Devoxx, c’est fini.
Si l’on devait résumer cet événement à un mot, ce serait : génial ! Devoxx fut un concentré de grandes conférences, de superbes rencontres, de talks géniaux et de bidouilleurs enthousiastes. Soit, toute l’effervescence d’une communauté de passionnés ! On ne savait simplement plus où donner de la tête.

Dans cet article, nous parlerons de la conférence présentée par Stéphane Bortzmeyer sur TLS lors de ce Devoxx 2014. Sujet parfaitement en accord avec l’actualité au vue des nombreuses publications autour de Heartbleed dans la presse de ces derniers jours.

Ce talk a été proposé en réaction à un article paru en 2012 : The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software.

Mais, avant d’aller plus loin, savez-vous ce qu’est TLS ?

TLS ? What’s that ?

TLS est un ensemble de protocoles permettant de sécuriser les échanges sur les réseaux entre 2 machines. TLS est un acronyme pour Transport Layer Security. Vous avez probablement déjà entendu parler de SSL. Et bien SSL, acronyme pour Secure Sockets Layer, est le prédécesseur de TLS. SSL a donné naissance à TLS et, comme l’explique si bien Stéphane, nous devrions parler de TLS plutôt que de SSL.

Durant ce talk, nous avons donc parlé de confidentialité, de ce que garantissait TLS mais surtout de ce qu’il ne garantissait pas…

La confidentialité & les attaques

Comme on nous l’explique, la base de la confidentialité passe par l’authentification (*). Mais une fois authentifié, comment peut-on être certain qu’une communication est sécurisée ? La solution magique apparaît-elle avec TLS ? Si une communication passe via le https, cela suffit-il à garantir la protection de l’échange ?

Pour un aspect plus visuel, voici un peu où se situe TLS :

TLS, Where are you ?? – Source : commons.wikimedia.org[/caption]

Comme nous avons pu l’entendre lors de la conférence, la sécurité n’est pas qu’une histoire de protocole. Bien sûr, cela en fait partie intégrante mais la sécurité est un principe.

Nous pouvons avoir les algos les plus performants afin de protéger la communication, si les extrémités sont poreuses, le risque vient moins du protocole de communication sécurisée via TLS que d’une des extrémités. Une extrémité poreuse pouvant permettre tout type d’attaque, du simple malware jusqu’au Man In The Middle.

TLS is secure, but…

Durant le talk, Stéphane nous rappelle ce que TLS ne garantit pas. En effet, il y a des choses que TLS ne peut régler. Il évoque notamment les extrémités lors d’une communication entre le serveur et le client. En tant que développeur, nous nous situons bien à une extrémité (enfin, aux deux même) et nous pouvons aussi y trouver :

• Des malwares (côté client)
• PRISM ou autres (coté serveur)

En effet, il n’est pas nécessaire d’avoir un serveur bourré de rootkit ou ciblé par PRISM pour perdre l’aspect sécurisé d’un tunnel de communication (rappelons que PRISM, tel qu’il nous a été présenté, permet une connexion direct aux serveurs Facebook, Apple, Google, … afin d’y collecter des données). Le simple fait d’avoir une application possédant des failles de sécurité pourrait entraîner l’effondrement de la sécurité du canal apportée par TLS.

Par exemple, sur votre Smartphone, vous utilisez une application sensible communiquant avec un serveur de manière sécurisé. Si, au sein de l’application mobile, la validité des certificats n’est pas vérifiée, alors c’est bien toute la communication qui peut être corrompue via un Man In The Middle.

Il reste un autre problème que ne résout pas TLS au cours d’un échange : la garantie de l’autorité de certification. Une autorité de certification peut tout à fait émettre des faux certificats et cela pour n’importe qui. Ce fut le cas pour Commodo et DigiNotar qui émettaient des faux certificats (pour Gmail par exemple). En effet nous faisons confiance au sein de notre navigateur à bon nombre d’autorités de certification. Mais sont-elles vraiment toutes dignes de confiance ?

Certificats dans Chrome[/caption]

Ainsi, l’orateur nous montre le résultat d’une usurpation d’un certificat en utilisant un exemple bien connu via une modification de son fichier host afin de pointer en local. Si l’on devait faire la manipulation, cela reviendrait à faire :

echo "127.0.0.1 toto.google.com" >> /etc/hosts

Notre apache doit également répondre quelque chose sur le port 443 (https). Pour ma part, voici ce que j’ai fait :

a2enmod ssl
a2ensite default-ssl
/etc/init.d/apache2 restart

Et voici dans un navigateur, le résultat que nous présentait le speaker :

Détection d’une usurpation de certificats dans Chrome[/caption]

Détection d’une usurpation de certificats dans Chrome
Google chrome ou Firefox sont en effet capable de s’apercevoir de l’usurpation d’identité d’un site web. Mais pour un public de développeurs, nous voici confronté à notre réalité : le code. Que se passe-t-il au sein d’un langage ? Pour cela Stéphane Bortzmeyer se base sur 4 exemples :

• L’utilitaire curl
• Php
• Python
• Java ( \o/ )

Curl

Quand on utilise l’utilitaire curl de la sorte : curl https://toto.google.com, voici le résulat :

curl et l’usurpation de certificats[/caption]

curl, par défaut, détecte bien l’usurpation que l’on essaie de mettre en place.

Php

Avec du PHP, on nous présente un cas un peu plus complexe. En effet celui-ci se base sur curl et la configuration d’utilitaire se fait grâce à la fonction curl_setopt dont voici la signature :

bool curl_setopt(resource $ch, int $option, mixed $value)

Il existe une option appelée “CURLOPT_SSL_VERIFYHOST” (il s’agit d’une constante). En tant que développeur bien intentionné, on serait tout à fait capable de passer cette valeur à true.

Seulement voilà, avec cette option, le 3ième paramètre devrait être un entier. La valeur 1 servant uniquement à vérifier l’existence d’un nom commun dans le certificat TLS et la valeur 2 à vérifier que le certificat correspond bien au nom d’hôte. Le fait de passer la valeur à true entraîne, via un cast php, de passer la valeur à 1 et devient donc une faille possible dans notre programme.

Durant la présentation, on nous indique cependant que cette confusion au sein du langage n’existe plus dans les dernières versions de php.

Python

En python, la librairie pour ouvrir des urls au sein de nos programmes s’appelle urllib2 que l’on peut utiliser de la manière suivante :

urllib2.urlopen('https://toto.google.com').read()

Cependant, la solution pour sécuriser ce simple code n’est pas si simple que cela (environ 40 lignes minimum).

Et nous découvrons que cela fonctionne sans aucun avertissement. Ci-dessous, voici un résultat sous python 3 de l’exemple montré durant la présentation et que j’ai tenté de reproduire.

Python et la détection d’usurpation[/caption]

Java

En Java (et oui, difficile de ne pas parler Java à Devoxx), en reprenant le code de la documentation Oracle (Reading Directly from a URL), voici le résultat :

Java face à un certificat usurpé[/caption]

Donc, par défaut en Java (tout comme en php), cela est sécurisé.

What’s next ?

Face à ces résultats, Stéphane nous explique que durant nos phases de tests, la sécurité ne doit surtout pas être négligée (ou pire, ignorée). Au contraire, elle doit être pleinement prise en compte durant la phase de développement. Et surtout, au cours de nos tests, les cas d’échecs sont tout aussi importants que les cas nominaux.

En effet, le fait de perdre la vérification sur la validité du certificat permettrait typiquement une attaque d’un Man In The Middle. D’autant plus que pour faire une attaque de ce type, il n’est pas nécessaire d’être au cœur du backbone. Faire simplement un relais wifi au sein d’une gare ou d’un aéroport suffit amplement. Avec un bon SSID, qui n’aurait pas envie de se connecter afin de consulter ses emails ?

Dans le contexte actuel, impossible de ne pas mentionner les failles au sein même des librairies, découvertes au fil du temps : de BEAST (utilisant une applet Java) à CRIME, nous finissons sur l’actualité avec la faille Heartbleed et ses conséquences directes.

Logo Heartbleed – Source : commons.wikimedia.org[/caption]

La présentation nous rappelle d’abord la difficulté pour les différentes librairies de trouver du support. La faille Heartbleed a rappelé qu’en tant que développeurs et consommateurs, nous ne sommes jamais à l’abri d’un bug au sein d’un programme. Enfin, l’investissement sur ces librairies Open Source qui sécurisent bien des sites e-commerces est bien faible par rapport aux nombres de sites qu’elles protègent.

En tant que développeurs, beaucoup d’entre nous possède un site web. Si vous êtes touché par Heartbleed, sachez que la CNIL explique sur son site web le processus à mettre en place suite à sa découverte. Dans le but de protéger vos utilisateurs, les propriétaires d’un site atteint par la faille doivent notamment invalider cookies, clés et certificats et les renouveler auprès d’une autorité de certification.

Conclusion

Durant cette conférence, Stéphane Bortzmeyer nous a sensibilisés sur les points faibles de la sécurité et sur le fait qu’il reste encore beaucoup à faire en matière de sécurité.
Idéalement il faudrait :

• De meilleurs API, sécurisées par défaut.
• Des développeurs plus attentifs lors de la lecture de la documentation.
• Et pour nous, l’écriture de meilleurs tests.

Il nous rappelle enfin que la plus grande sécurité en terme de données, c’est surtout de ne pas en récolter !

Un grand merci à Stéphane Bortzmeyer pour cette très belle conférence !

Remarque :

• () En terme d’authentification, Jérôme Leleu a présenté durant un *Tools in Action une librairie qu’il a développé : pac4j