[DevoxxFR 2014] Utiliser TLS sans se tromper

Cette année à Devoxx ont eu lieu de nombreuses conférences intéressantes et une a retenu toute mon attention : Utiliser TLS sans se tromper. Conférence présentée par Stéphane Bortzmeyer, portant sur le protocole TLS (Transport Layer Security) et sur ce contre quoi il protège et contre quoi il ne protège pas.

En tant que développeur, la sécurité est souvent une chose sur laquelle on ne s’attarde que trop peu. C’est très souvent le sujet qu’on laisse aux responsables de l’infrastructure en arguant “passez en HTTPS et on aura un site sécurisé”. Encore faut-il comprendre ce qu’on sécurise réellement.

On commence donc le traitement en apprenant qu’il ne faut plus parler de SSL (depuis 2001) mais bien de TLS. Que ce protocole permet de sécuriser les protocoles HTTP mais aussi FTP, SMTP… et très rapidement, l’orateur nous précise ce que TLS fait. Il crypte les informations envoyées entre deux points et permet de se prémunir contre les attaques de l’homme du milieu. Ce type d’attaque est assez simple à comprendre : l’attaquant se place entre le client et le serveur et intercepte toutes les requêtes qui transitent entre les deux.

C’est alors que la paranoïa de la salle va monter d’un cran. Il explique comment il est simple de se comporter en homme du milieu. Il suffit d’ouvrir un point wifi gratuit avec comme nom “wifi gratuit” et vous voilà maître de tout ce qui transite entre les naïfs voulant économiser leur forfait data et leurs sites préférés. Il enchaîne sur la facilité avec laquelle on peut émettre un faux certificat et les lacunes présentes dans beaucoup d’API qui ne vérifient pas que le certificat est bien correct. Il tacle allègrement plusieurs API en différents langages (Python, PHP, Java) qui offrent la possibilité de désactiver la sécurité voir même de proposer par défaut de ne pas l’activer.

Avant de nous laisser le moindre espoir qu’au moins une des applications qu’on a pu développer ne soit pas un énorme panier percé de failles de sécurité, il continue à saper notre confiance en enchaînant sur les cookies, les principaux responsables de failles béantes des applications web. Première info et pas des moindres, les cookies sont automatiquement envoyés vers le serveur avec la requête, ce qui rend la tâche très facile à notre bon vieux troisième homme pour voler le token de session que Java place dans votre navigateur préféré. Vous imaginez facilement ce que peut faire quelqu’un volant votre JSessionid sur votre vieille application Struts encore en production. On apprendra quand même qu’avec Servlet 3, il est possible de sécuriser l’envoi de cookie et qu’elle est désactivée par défaut.

S’ensuit une longue agonie sur la majorité des failles de sécurité des applications web qui, une fois terminée, m’a donné envie de jeter mon portable, mes applis web et de changer de métier. On a le droit à une petite parenthèse sur OpenSSL et la dernière faille de sécurité trouvée (HeartBleed) et de préciser que le projet est maintenu par une personne avec un budget de 2000$ financé par les sociétés tierces. C’est bien maigre pour une technologie présente dans la très large majorité des sites E-commerce du web. Et tout cela avant de nous rappeler que Google, Twitter, Facebook et bien d’autres collectionnent déjà un nombre croissant de données sur nous. Et quand ils ne sont pas occupés à les vendre au plus offrant, il les mettent à notre disposition n’importe où.

Et c’est là que notre bourreau voulait en venir depuis le début, TLS protège uniquement les infos pendant leur transport et ne protège pas du tout les points de départ et d’arrivée. Si l’un des deux n’est pas sûr, c’est toute la requête qui ne l’est plus. Et contrairement à ce que l’on pense, ce n’est pas toujours le client qui possède un point d’accès non fiable. Les révélations de Snowden sur la NSA ont montré que tout ce qui transite chez Google entre leurs serveurs n’est pas sécurisé et qu’il est beaucoup plus simple d’écouter l’information là où elle est centralisée et n’est pas plus sécurisée que chez des millions d’utilisateurs. Et pour conclure que plutôt que de tenter de sécuriser toutes vos données qui de toute façon finiront par être récupérées, il vaut mieux réfléchir en stratégie de transport des informations. Par exemple, multiplier l’envoi de données confidentielles va multiplier le nombre de risques qu’elles soit interceptées. Ou encore ne pas envoyer le mot de passe avec cet objet Compte que votre serveur envoie au navigateur, parce que l’utilisateur veut afficher son pseudo trop classe qu’il a enfin trouvé. Le meilleur mécanisme de sécurité reste encore d’en dire le moins possible.

En plus d’avoir pu sensibiliser une salle pleine à craquer sur la sécurité, Stéphane Bortzmeyer nous a montré ses talents de showman pour rendre la conférence très facile à suivre et très plaisante. A défaut de m’avoir fait comprendre que je ne pourrais pas faire son travail et continuer de me balader sur Internet innocemment, cette conférence m’aura aidé à comprendre les failles de méthodes de développement et qu’il est vain de croire qu’une application peut être sûr à 100% (merci HeartBleed, bon timing). Il est plus efficace de limiter les données transitant sur le réseau que de croire que l’on peut tout sécuriser.