article.md 9.6KB
title: Sécurité, twitter, confiance et habitudes slug: securite-twitter-confiance-habitudes date: 2009-10-13 12:32:37 type: post vignette: images/logos/twitter-ssl.png contextual_title1: Stratégie de sauvegarde SSD + NAS contextual_url1: 20100429-strategie-de-sauvegarde-ssd-nas contextual_title2: Retours à chaud sur Paris-Web 2009 contextual_url2: 20091012-retours-chaud-sur-paris-web-2009 contextual_title3: Ouvert et décentralisé, est-ce suffisant ? contextual_url3: 20090615-ouvert-et-decentralise-est-ce-suffisant
Paris Web c’est la grande messe des intervenants du web en France. Le samedi pour les ateliers communautaires on y retrouve un nombre impressionnant de geeks au mètre carré. Ils savent ce qu’est la sécurité, ils connaissent l’importance de la sécurisation d’un mot de passe, ce qu’est un certificat SSL, ce que veut dire “man in the middle” dans un contexte de sécurité. Bref, ce sont des gens sûrs, des gens biens et compétents.
Note : ce billet a été rédigé par Éric Daspet.
À Paris-Web tout le monde tweet
Le samedi on commence par un atelier sécurité. Pendant ce temps nos geeks se connectent à Internet pour commenter et discuter en temps réel sur l’atelier, via twitter. C’est un outil inutile mais magique, qui permet de partager des réactions à chaud.
L’école d’ingénieur qui nous héberge propose un wifi avec un proxy pour accéder à Internet. Premier réflexe de beaucoup, on sort tweetdeck pour se connecter. Le logiciel tente d’accéder à twitter, mais s’arrête : erreur SSL. Bref, ça ne fonctionne pas. Pas grave, on lance Firefox, http://twitter.com/. Une partie est déjà connectée et commence à twitter, les autres se connectent.
Mais mais …. que ne viennent-ils pas de faire ?
Nous sommes dans une zone hostile
Nous sommes dans une école d’ingénieurs, plein de geeks, jeunes, prêts à faire des bêtises. Nous passons par du wifi, ce qui en soi n’est déjà pas d’une sécurité à toute épreuve contre les écoutes réseau. Nous passons par un proxy, donc nos connexions sont interceptées. Souvent dans les écoles d’ingénieurs les élèves participent à l’infrastructure. Peut être gèrent-ils le proxy lui-même. Parfois sensibiliser à la sécurité fait partie de l’école au point que tenter de trouver des failles est un jeu accepté voire encouragé. Bref, nous ne sommes pas dans un lieu “de confiance”. C’est même tout l’inverse.
Dans cet environnement hostile les applicatifs desktop et Firefox envoient des messages d’erreur ou d’avertissement à propos de certificats SSL cassés. Le geek clique rapidement “continuer”, “je comprend les risques”, “ajouter une exception”.
Le modèle de sécurité SSL se base sur le concept de réseau de confiance, ou d’autorité de certification, ce qui revient au même. Quand on dialogue avec un site en SSL, on a deux sécurités : le chiffrement et la signature. Le chiffrement c’est ce qui permet d’éviter que quelqu’un puisse écouter ce qu’on échange. Ça parait le principal mais finalement c’est totalement inutile sans la partie signature. La signature c’est ce qui permet de s’assurer qu’on parle à la bonne personne. Qu’importe le chiffrement si notre interlocuteur n’est pas le bon ?
Les messages d’erreur liés à SSL impliquent exactement ça : on ne discute pas avec twitter mais avec un proxy. Le chiffrement va jusqu’au proxy. Ce dernier peut lire les échanges, modifier les données, retenir les mots de passe et les réutiliser. Le proxy fait suivre toutes vos requêtes à twitter, ou pas, sans modification ni stockage, ou peut être que si. Quand le proxy veut faire ça, il “casse” la signature, on sait que quelqu’un intercepte nos communications. C’est ce qu’il s’est passé aux ateliers Paris-Web.
L’interface chaise - clavier
Force est de constater qu’on a l’exemple même d’un échec flagrant en termes de sécurité. Nos geeks ont ajouté des exceptions et validé des certificats cassés toute la matinée, pendant une session nommée “sécurité” et une à propos d’authentification par certificat SSL sur des réseaux sociaux.
Ce n’est pas parce qu’on connait les risques et qu’on est sensibilisé à la sécurité que les habitudes sont meilleures. Nos geeks viennent tous de valider sans réellement y penser que quelqu’un intercepte leurs communications théoriquement sécurisées, dans un environnement qu’on sait hostile. Ces gens qui adorent SSL, qui ont toujours peur pour leurs mots de passe soient interceptés, qui sont paranoïaques sur leur vie privée, viennent de violer tous leurs principes.
Il y a eu toute une polémique lors de la conception des pages d’erreur SSL de Firefox. Faut-il permettre aux gens de créer des exceptions ? Faciliter ce processus ? C’était le cas avant, les gens cliquaient sur “continuer quand même” sans vraiment réfléchir ou prendre conscience du problème. Mozilla a souhaité mettre en place des messages d’erreur plus forts, empêchant ou dissuadant les gens de se connecter avec une sécurité cassée. Les informaticiens ont râlé, avec des arguments sensés. Il est donc toujours possible d’ajouter une exception même si l’erreur est plus forte qu’avant.
Peut-être est-ce une erreur. Même les geeks font de grossières erreurs au niveau de l’interface chaise - clavier. Ils savent, mais n’agissent pas en conséquence. Eux ne lisent même pas les messages d’erreur et ne sont pas impressionnés par les icônes jaunes ou rouges. Peut être faudrait-il leur masquer à eux aussi la possibilité d’ajouter des exceptions.
Informaticiens : SSL est là pour votre bien. Utilisez le, toujours. Ne validez pas d’exception, ou pas en situation d’itinérance, pas pour un site qui n’en demande pas en temps normal.
Résoudre le problème
Il n’y a aucun doute, tous nos geeks sont coupables. Ils ont cassé la sécurité, en connaissance de cause, simplement par manque de réflexion. L’éducation et l’information peuvent aider, mais il est humain de chercher “à ce que ça fonctionne”. L’alternative, pas de connexion Internet, n’était pas suffisamment acceptable pour qu’ils réfléchissent aux conséquences.
Le problème c’est que l’utilisateur avancé tombe assez régulièrement sur des sites avec des certificats auto-signés qu’il est raisonnable d’accepter. Les sites internes à son entreprise, les sites des copains, les sites associatifs, etc. Plus l’utilisateur réalise d’exceptions, plus il sera à même d’en réaliser une nouvelle sans y réfléchir un jour où il y aura une réelle brèche de sécurité. En montrant des pages d’erreurs visuellement différentes suivant les cas, on permet à l’utilisateur de ne pas ignorer les erreurs importantes, simplement par habitude.
Il semble y avoir un scénario très clairement identifiable dans lesquels valider une exception SSL ne devrait pas être proposé : quand le site proposait il y a peu (pour vous ou pour un nombre important d’internautes) un certificat valide et certifié par un tiers de confiance. Si aujourd’hui le certificat est auto-signé ou invalide, il y a certainement un problème de sécurité qui ne relève pas des cas “acceptables” habituels. Dans ces cas là Mozilla donne actuellement un choix qui ne devrait pas exister. Il s’agit d’une erreur forte.
J’envisage l’enchainement qui suit pour la vérification du certificat SSL :
- Le certificat est-il valide et certifié par un tiers de confiance ? ou validé en tant qu’exception dans Firefox ? -> si oui alors tout va bien
- On fait une requête http sans ssl vers un prestataire de confiance en lui indiquant le site à joindre et le certificat. Le prestataire nous répond (dans un message signé pour éviter qu’il ne soit falsifié) si :
- le site est injoignable depuis l’extérieur (site intranet, local) -> dans ce cas on saute au point 3
- le site répond avec un certificat différent de celui qu’on a actuellement -> erreur forte, il y a une brèche de sécurité clairement identifiée
- le site répondait avec un certificat valide et certifié par un tiers de confiance il y a peu -> erreur forte, il y a une brèche de sécurité clairement identifiée
- la signature du prestataire est invalide -> erreur forte, il y a certainement une brèche de sécurité
- le prestataire ne répond pas -> on saute au point 3 mais en rajoutant un avertissement clair sur le fait que le prestataire de vérification est injoignable
- Si on ne souhaite pas passer par un tiers ou que le site est un site local :
- j’ai déjà visité ce site, il avait un certificat valide et certifié par un tiers de confiance il y a peu -> erreur forte, il y a une brèche de sécurité clairement identifiée
- j’ai déjà visité ce site, il a toujours eu un certificat invalide ou auto-signé, mais le certificat a changé depuis -> erreur standard, insister sur le fait que le certificat a changé, “est-il vraissemblable que le certificat ait changé ?”, on permet de créer une exception
- je n’ai jamais visité ce site, il y a de bonnes chances qu’il s’agisse d’une exception “acceptable” -> avertissement, message similaire à la page d’erreur actuelle, on permet de créer une exception sans trop stresser l’utilisateur
L’extension perspectives réalise déjà une petite partie de ce processus, même si pas de manière idéale. Il serait à mon avis très utile que Mozilla avance sur quelque chose de similaire pour bien dissocier les erreurs graves des “on ne sait pas”.