Utiliser TLS sans se tromper

Eh bien voilà, Devoxx, c'est fini.
Si l'on devait résumer cet événement en 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 vu 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 est un ensemble de protocoles permettant de sécuriser les échanges sur les réseaux entre deux machines. TLS est un sigle pour Transport Layer Security. Vous avez probablement déjà entendu parler de SSL. Eh bien, SSL, sigle 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…

Comme on nous l'explique, la base de la confidentialité passe par l'authentification(1). 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 :

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 algorithmes 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.

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éveloppeurs, 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 (côté 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 directe 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ée. 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 ?

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 :

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

• l'utilitaire curl ;
• Php ;
• Python ;
• Java ( \o/ ).

IV-A. Curl▲

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

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

IV-B. PHP▲

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

IV-C. Python▲

En Python, la bibliothèque pour ouvrir des URL au sein de nos programmes s'appelle urllib2 que l'on peut utiliser de la manière suivante :

 

Sélectionnez

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.

IV-D. 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 :

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

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 Wi-Fi 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 bibliothèques, 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.

La présentation nous rappelle d'abord la difficulté pour les différentes bibliothèques 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 bogue au sein d'un programme. Enfin, l'investissement sur ces bibliothèques 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èdent 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.

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 meilleures 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 termes 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 !

Cet article a été publié avec l'aimable autorisation de la société Soat.

Nous tenons à remercier Jacques THÉRY pour sa relecture orthographique attentive de cet article et Régis Pouiller pour la mise au gabarit.