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".
11 Commentaires
Le comportement décrit est tout simplement effarant même s'il n'est pas très surprenant. Un ami, la première semaine de son embauche a fait un dump des mots de passe et autres info sensibles de tous les employés de son nouvel employeur puis les a affiché au tableau commun de cette boîte... spécialisé dans la sécurité informatique.
Je ne sais pas si modifier Firefox dans ce sens peut changer quelque chose (même si ça serait sans doute pas mal). Ce sont les mêmes personnes qui ont levé la main pour répondre à la question "avez-vous déjà donné votre login et mot de passe twitter sur un autre service en ligne ?" :)
1 | Olivier, le 13 October 2009 à 13h
D'un coup, je me sens tout nu.
En tout cas, un nouvelle interface pour Firefox basée sur les propositions d'Éric serait la bienvenue.
2 | Thomas, le 13 October 2009 à 14h
Tes propositions sont en effet intéressantes. Tu en as parlé à des gens de la MoFo ? Tu pourrais peut-être ouvrir un ticket sur Bugzilla.
Un des projets en cours pour les prochaines versions de Firefox est justement de revoir l'ergonomie des pages d'erreur liées au réseau : https://wiki.mozilla.org/Firefox/Projects/Network_Error_Pages Ta proposition me semble tout à fait entrer dans ce cadre.
3 | Clochix, le 13 October 2009 à 15h
On se rapproche d'un problème que l'on retrouve sur les iphone ou androïd ou l'on peut installer une application super jolie pour twitter ou voir ses stats Google Analytic.
C'est très pratique, sauf que l'éditeur de l'application n'est pas l'éditeur du service, et le code source n'étant pas accessible, cela revient à fournir ses identifiants à n'importe qui !
Ca à l'apparence du sécurisé, mais ca n'en est pas...
4 | Martin, le 13 October 2009 à 16h
Je suis un peu circonspect par rapport à l'utilisation du tiers de confiance.
2.1 pourquoi pas
2.2 l'externe ne correspond pas à l'interne
2.3 identique à 3.1 ?
2.4 faux tiers de confiance
2.5 on est dans un jardin
2.1, 2.4 et 2.5 sont juste la gestion du tiers de confiance, 2.3 me semble identique à 3.1. Reste 2.2.
Quels sont les cas possibles ?
a. authentification sur SSL à la Chilli Hotspot (Neuf Wifi, Free Wifi, ...) pour la première page
b. proxy HTTPS à la petite semaine, qui plutôt que de tunneler interceptent le trafic
c. homme dans le milieu
a. est un cas normal et transitoire, une fois l'authentification passée il n'y parait plus.
b. et c. sont équivalents, un proxy HTTPS qui fonctionne comme ça est un homme dans le milieu
La stratégie du prestataire de référence est donc de lui demander "toi aussi tu vois le type au milieu ?", stratégie pertinente surtout si c'est le premier accès à ce service (et il faut toujours faire attention au premier accès), mais déjouée si l'attaque se fait sur un serveur non accessible depuis l'extérieur. Pas très propre au niveau raisonnement, mais je reste non convaincu.
D'un autre côté, une chose qu'il serait intéressant d'exploiter et que je ne vois pas là, est d'élargir ce qu'on connaît des hôtes au niveau des OU des certificats présentés et connus. Et dernier point, dans ce flux je ne vois pas la distinction entre les différentes causes d'invalidité (CRLé, AC inconnue, expirée), mais peut-être est-ce sous-entendu dans "message par défaut" ?
5 | Damien B, le 13 October 2009 à 18h
Ça ne change rien de renforcer la sécurité sur FireFox : si les gens veulent quand même contourner la protection ils pourront toujours : passer par Opera, Safari, w3m, etc.
Et il ne faut jamais empêcher COMPLÈTEMENT un utilisateur de rentrer quand même sur un site même si le certificat n'est pas valide.
Je prends un exemple : j'ai moi-même un serveur, et un des sites hébergés dessus n'est accessible que par HTTPS. Seulement, je n'ai pas d'argent à dépenser pour faire un vrai certificat SSL. J'utilise donc un certificat auto-signé.
Et si on m'empêchait d'aller sur ce site, mon propre site alors que je suis sûr que ça n'est pas malveillant puisque c'est mon site ?
Cela dit je suis d'accord que compliquer fortement la tâche d'accepter un certificat SSL jugé non valide, c'est bien. Mais il faut toujours laisser une possibilité de passer outre !
6 | DJ Fox, le 13 October 2009 à 19h
Ça ne m'étonne pas.
On prend l'habitude d'ajouter ces exceptions, et les informaticiens aident parfois ce processus.
Par exemple, dans mon école d'ingénieurs, le service informatique a récemment passé l'intranet et le webmail en https, mais ils ne veulent apparemment pas payer le certificat.
Donc ils ont expliqué à tous les élèves et profs comment ajouter une exception dans firefox.
Du coup, tous les élèves, profs et administratifs, pour la plupart non geek, sont familiers avec l'ajout d'exception dans firefox ; d'autant qu'il faut répéter l'opération à chaque session sur les ordinateurs publics (dans l'école).
7 | bleno, le 13 October 2009 à 22h
> 2.1, 2.4 et 2.5 sont juste la gestion du tiers de confiance
Pas tout à fait pour 2.1, puisqu'il peut être tout à fait légitime qu'un site réponde en interne et pas en externe, mais oui, ces trois points sont là pour gérer les différents cas potentiels. J'ai tenté justement de faire une procédure complète et pas juste les deux cas différent de d'ordinaire.
> 2.2 l'externe ne correspond pas à l'interne
Je ne vois pas de cas concret où pour une même URL un site aurait utilité à avoir des certificat différent en interne et en externe. Le cas ne s'est jamais présenté à moi. Un exemple ?
> 2.3 identique à 3.1 ?
Oui, sauf que si moi je ne suis pas passé (cas 3.1), peut être que quelqu'un est lui déjà passé (2.3), et avec un peu de chances il sont suffisamment nombreux pour que si le résultat du test soit négatif, j'ai à m'inquiéter. Les deux sont intéressants
> a. est un cas normal et transitoire, une fois l'authentification passée il n'y parait plus.
C'est le cas le pire en fait, puisqu'il incite à ajouter une exception qui est clairement inutile et dommageable (à ce moment là on ne sait pas encore si on est sur un spot wifi falsifié ou pas).
Clairement la page d'erreur *doit* préciser cette éventualité et inciter à visiter un site http sans SSL pour vérifier (et là la redirection ne nécessitera pas d'exception SSL). Dans l'idéal Mozilla pourrait même le faire tout seul (tenter http://google.com/ et regarder s'il y a une redirection, si oui on renvoie vers la page en question, sinon on fait une erreur SSL)
Sinon oui, le prestataire de confiance est totalement déjoué s'il s'agit d'un premier accès sur un site intranet non disponible depuis l'extérieur. Le cas me semble suffisamment limité pour que le défaut ne soit pas important. Surtout que le prestataire de confiance n'est pas là pour te dire "là l'exception est sûre", mais plutot "là l'exception est certainement une mauvaise idée". Bref, si le prestataire de confiance n'est pas vraiment "de confiance" ou s'il n'est pas utile, tu ne perds rien. Tu ne peux que y gagner.
@DJFox: Nous sommes d'accord. D'ailleurs Mozilla est arrivé à la même conclusion. Maintenant le jeu c'est justement de tenter de savoir si on est potentiellement dans ton cas, ou si on est certainement dans un cas de "man in the middle". Si ton site a ou a eu un certificat SSL valide et certifié, et que ce n'est pas le cas sur le WIFI auquel je viens de me connecter, là il y a problème. C'est uniquement de ça que je parle, et dans ce cas où proposer une exception a peu de sens. Ca ne concerne donc absolument pas ton site en https auto-signé.
@bleno: qu'ils aient un certificat ssl auto-signé pour leur webmail ne me choque pas. Qu'ils n'aient pas créé une fausse autorité de certification et qu'ils n'en aient pas installé le certificat racine sur tous les postes et portables de l'école, pour une école d'ingénieurs ce n'est pas très malin.
Maintenant ces cas légitimes existent, c'est bien dans cette optique que ça faudrait le coup d'améliorer un peu les erreurs et leurs contextes.
8 | Eric, le 14 October 2009 à 00h
Eric: en fait, je m'interroge plus sur la probabilité réelle d'être en face de 2.2 sans que ce soit visible d'une autre manière. C'est sur ces cas là aussi que je trouve qu'on n'exploite pas assez les OU.
Sinon pour (a), une méthode est effectivement de chercher un serveur connu (pas forcément Google qui bidouille et au niveau DNS et au niveau redirection) et de voir si on arrive vers la même redirection foireuse.
9 | Damien B, le 14 October 2009 à 21h
Eric: dans la réponse à bleno, pourquoi qualifier l'autorité de certification de "fausse" ? Elle est aussi vrai que celle de Verisign et consorts :-)
10 | Damien B, le 14 October 2009 à 23h
Effectivement, qualifier une autorité de confiance crée pour l'occasion de "fausse" n'est pas malin de ma part. C'est à défaut d'avoir trouvé un terme approprié. Peut être que "locale" aurait été moins péjoratif.
11 | Eric, le 15 October 2009 à 00h
Ajouter un commentaire