SSL ou l'absence de la moindre assurance

Par SwissTengu @SwissTengu @SwissTengu — 19.05.2014
SSL. Heartbleed. TLS Triple Handhshake. gnuTLS. Des noms, des abréviations, des failles, des trous de sécurité. 

Ils font les gros titres, ou restent invisibles pour les personnes non-techniques, ou les simples utilisateurs. 

Pourtant, il est nécessaire de comprendre comment tout cela marche, ce que c'est réellement, pour comprendre pourquoi et comment ces "trucs" sont censés nous protéger — que ce soit des données transmises à notre banque, ou simplement protéger le fait qu'on est sur, au hasard EthACK, à lire un contenu quelconque. 

Le document va se découper en 5 parties : 
  • HTTPS: à quoi ça sert, en fait ? 
  • HTTPS: le petit cadenas, et sa signification 
  • Explications des attaques possibles sur une connexion "sécurisée" 
  • Certificats invalides : comment se comporter
  • Extensions utiles pour Firefox et Chromium 

HTTPS : son utilité
Au début d'Internet, tout était plein de bisounours, de poney et de licornes. Rien n'était chiffré, c'était la fête du slip, de toutes façons il y avait quoi, 100 personnes capables d'employer le Réseau. Puis ça s'est démocratisé. Et l'humain étant ce qu'il est (curieux, fouille-merde etc), on s'est rendu compte qu'il faudrait sécuriser un poil les choses, entre autres chiffrer les communications.  HTTPS1 est né.

Le petit cadenas que vous voyez dans votre navigateur a plusieurs significations : il vous indique que la connexion est chiffrée, ET que le site possède un certificat signé par une autorité ET que votre système (ou du moins votre navigateur) reconnaît cette autorité comme "valide". 

Cool, donc on a une chaîne de confiance complète. Oui, mais. 

Le problème, c'est l'empilement de significations : dans le cas d'un certificat auto-signé (self-signed certificate), le navigateur va vous hurler dessus, parce que seule le premier point est valide; le reste, par contre, "booohh je connais pas, alors je te plante un bon gros avertissement". 
Et c'est là que le bât blesse. Et c'est là que se pose tout le problème de la conception même du truc. 

SSL (et HTTPS par extension logique) repose sur la confiance. On a des autorités de certification (grosses entités, du genre de Norton, StartSSL, Komodo etc) qui ont réussi à convaincre qu'elles sont biens, qu'elles suivent les règles, et qu'on peut leur faire confiance. Partant de là, la plupart des systèmes et des navigateurs intègrent directement leur certificat d'autorité. Un système Debian de base possède plus de 400 certificats d'autorité, signifiant qu'il fait d'office confiance à plus de 400 entités. Dont VOUS, utilisateurs, ne savez rien ou presque. 

Vu que c'est basé sur la confiance, un certificat auto-signé débarquant comme un coquelicot dans un champ de maïs va faire un peu tache : on ne le connaît pas, on ne sait pas qui c'est, on ne sait pas le niveau de confiance qu'on peut lui accorder. Pensez, un étranger, ça ne peut qu'être mauvais2
Forcément. 

Du coup, vous ramassez un warning. Et, comme vous ne savez pas trop ce que c'est, que, comme la plupart des gens, vous cliquez sur "OK" au moindre message de votre système (allez, avouez), vous allez forcer votre navigateur à passer outre. Et là, en fait, vous êtes potentiellement dans la merde.

HTTPS, le petit cadenas
Comme dit précédemment, le cadenas signifie que la connexion entre votre navigateur (Firefox, Chromium, Safari etc) et le site que vous visitez est censée être chiffrée (et authentifiée par une entité tiers que vous ne connaissez pas).
Cela implique, logiquement, que personne ne peut venir écouter ce que vous faites. Dans un monde idéal, si votre fournisseur d'accès se met à écouter votre trafic, il ne pourrait voir passer que des connexions vers des adresses IP, sans savoir quel site vous visitez réellement. 

En simplifiant, une connexion HTTP standard se fait ainsi : 
  • le navigateur demande au système "hey gros, c'est quoi l'IP de www.ethack.org ?" 
  • s'ensuit une résolution DNS interne (le système a la réponse en cache, ouva demander plus loin) 
  • le navigateur ouvre une connexion (socket) vers le serveur répondant à l'IP, et lui envoie ensuite des informations, appelées "header  HTTP"  

Parmi ces headers, "Host" est celui qui permettra au serveur de savoir quel site est appelé. C'est pratique dans le cas où plusieurs sites sont hébergés sur le même serveur. 

Dans le cas d'une connexion HTTPS, donc chiffrée, les headers sont envoyés à travers le tunnel SSL créé lors de la connexion initiale. C'est donc protégé contre les écoutes indélicates 

Du moins, c'est la théorie… 

Les attaques
MitM. Drôle d'acronyme hein ? Sa signification est nettement moins sympa : Man in the Middle, littéralement "l'homme du milieu". De quel milieu ? De votre connexion. En effet, cette attaque permet à quelqu'un de se mettre entre vous et le serveur, et d'écouter ce que vous faites. 
Hmm… mais… attendez. On a dit tantôt que la communication était chiffrée, et donc évitait ce genre de trucs… Comment que c'est-y-tu-donc possible ?! 

Plusieurs manières permettent de faire un MitM avec succès. En voici X des principales : une demandant à l'utilisateur de réfléchir, l'autre lui demandant d'être prudent de manière générale. 

Le certificat auto-signé
C'est la plus simple, et celle qui s'évite le plus facilement : votre navigateur va lever une alerte rouge vif en expliquant que le certificat n'est pas valide. En regardant les détails, vous apprendrez qu'il est signé par une autorité inconnue, voire pas du tout signé. Vous allez donc accepter le certificat les yeux fermés, comme d'habitude… ? 
Non. 

S'il s'agit d'un site officiel, par exemple votre banque, ou un site de l'état, ou un site marchand, accepter ce certificat et passer outre vous expose à un vol de données (au minimum). Par contre, s'il s'agit de votre site personnel, ou du site d'un pote (qui vous a averti que le certificat était auto-signé)… il est possible de passer outre l'avertissement. 
Mais ça demande un poil de réflexion et de logique. 

Le certificat volé
Hey, vous vous souvenez de Heartbleed ? Des clefs privées (le truc qui n'est pas censé se trouver dans la nature) ont été volées3. Ce qui permet de remonter un site avec le certificat et la clef volée en moins de 10 secondes. Et, en plus, d'avoir un certificat *valide*. 
Hmm… attendez. Donc on peut se retrouver avec un certificat valide mais qui est pas valide ?! Ouep. Et Heartbleed n'est pas le seul moyen de le faire. 

Mais… et la chaîne de confiance ?! Bah elle est brisée. 

Suite à Hearbleed, les différentes mesures aurait dû être prises par les sites sérieux : 
  • mettre les serveurs à jour immédiatement 
  • générer de nouvelles clefs privées et certificats 
  • révoquer les anciens certificats 
  • communiquer sur le problème et la résolution de manière complète
  • contrôlent que les certificats soient valides de manière approfondie suite à ce genre de problèmes. 

Seulement… Cela n'a pas été fait partout : 
  • certains sites n'étaient pas affectés par la faille (mais communication absente — que croire, que faire ?!) 
  • certains sites n'ont pas révoqués les certificats (mais les ont quand même changés, c'est déjà pas mal) 
  • certains sites n'ont pas encore fait les mises à jour (un sacré paquet à ce qu'on dit) 

Dans tous les cas : la communication était absente, vaseuse au mieux. Les révocations, si elles ont été faites, ne sont prise en compte que dans Firefox, ce dernier étant configuré par défaut pour prendre en compte les CRL, Certificate Revocation List, des autrités de certifications. Chromium possède cette option, mais elle n'est pas activée par défaut. 

Ce qui signifie une chose assez grave, en fait : la chaîne de confiance est cassée (encore…). L'utilisateur standard n'a AUCUN moyen de réellement s'assurer que son site bancaire est bien le bon, que personne n'écoute ses communications. 

Et il y a les trucs funs, genre la dernière trouvaille au niveau du protocole TLS, employé pour ainsi dire partout (pour une fois que tout le monde ou presque se met d'accord, faut évidemment qu'il y ait un truc vaseux…). 
Ou encore des virus/vers/troyens qui installent des certificats à votre insu, évitant ainsi à votre navigateur de lever des alertes sur les certificats auto-signés…

Bref. Les accès chiffrés, c'est bien, mais on ne peut simplement pas faire confiance. Actuellement, il faut contrôler les dates de création des certificats, le signataire, et encore bien d'autres choses si on veut bien faire. 

Heureusement, certaines extensions Firefox (et normalement aussi disponibles sur Chromium) peuvent nous aider dans cette tâche (on en verra un peu plus bas). 

Comment se comporter face à un certificat détecté comme faux
Comme mentionné plus haut, il n'y a pas 42 façons de se comporter : par défaut, "fuir". Si on ne comprend pas, si on ne sait pas, on ne va pas sur le site. Point. 

Si, par contre, on a le temps d'analyser et de comprendre, on peut se risquer à ne pas fuir de suite : une analyse attentive du problème peut, dans certains cas, mener à avertir l'éditeur du site pour lui signaler que son certificat est faux/mal installé/échu ou autres. Ça m'est déjà arrivé de le faire. Plus d'une fois. 

De manière générale, sur Firefox, on a la possibilité de contrôler le certificat avant de l'accepter. Cela nous donnera la raison précise de l'erreur relevée. Mais, comme dit plus haut : dans le doute, refuser. Il en va de la sécurité des données que vous seriez amené à transmettre, de la sécurité de vos communications. Un certificat invalide n'est pas anodin.

Les extensions
La première qui vient en tête, c'est Certificate Patrol4. Elle va se charger automatiquement de quelques checks, vous simplifiant la vie et améliorant ainsi la sécurité. 
Elle ne fera pas de miracle, mais vous permettra de savoir quand un site change de certificat (en vous montrant les différences au niveau des dates, autorité de certification ou autres). Elle note aussi le risque que représente le changement d'un certificat, par exemple s'il arrivait à échéance le niveau sera moins élevé que s'il avait été émis quelques jours plus tôt, puis remplacé. 
Le seul problème avec cette application est le niveau de verbosité : vous risquez d'être assez vite dégoûté du nombre de popups qu'elle crée, surtout si vous employez google, facebook ou autres gros sites du genre, qui semblent incapables d'avoir le même certificat sur leurs différents points d'entrée (un comble…). 

Une autre extension, HTTPS Everywhere5, est un bon complément à la précédente : elle vous fera passer automatiquement à la version SSL du site quand disponible. Le seul problème : elle se base sur une liste définie de sites — elle n'ira par exemple pas chercher toute seule si un site propose une version SSL ou non. D'un autre côté, pour avoir testé une extension qui faisait cela, ce n'est pas plus mal : certains sites ne fournissent pas le même contenu en SSL, voire sont cassés… Autant dire que ce genre de choses ne devrait pas exister à l'heure actuelle !

En conclusion
HTTPS, c'est joli, ça part d'un bon sentiment. Mais, de par le fonctionnement même de la chose, ça ne peut plus marcher. On sait, en tous cas depuis les révélations de Snowden, que la confiance ne suffit plus. Quand vous allez sur le site de votre banque, il vous fut procéder à quelques contrôles. Quant vous recevez un mail soi-disant de votre banque, ou de facebook ou autres, il vous faut avoir un esprit critique. Vous ne pouvez tout simplement plus cliquer aveuglément partout.
Ouvrez les yeux, soyez attentif. C'est, à l'heure actuelle, la seule manière d'éviter les pièges évidents. Et même ainsi, personne n'est à l'abri d'une erreur.


Commentaires (0)

Ajouter un commentaire