20/06/2016

Le S de HTTPS n'est pas là pour faire joli






Sur Internet, quand un utilisateur veut se connecter à un site internet via un navigateur web (Firefox, Chrome, Internet Explorer ...), celui-ci communique avec le site en question à l'aide du protocole HTTP (HyperText Transport Protocol).

Un protocole informatique définit une manière de partager les informations pour qu'elles soient comprises des deux côtés de l'échange (dans la vraie vie par exemple, la grammaire française définit le protocole utilisé pour communiquer). Ce protocole est indispensable pour naviguer sur Internet puisqu'il permet d'avoir accès à tout type de document par l'intermédiaire d’un navigateur web. En bref, dès que tu te promènes sur Internet et que tu veux accéder à des informations, ces dernières transiteront à l'aide du protocole HTTP.

Les premières pierres d'Internet (dont le protocole HTTP) ont été posées par l'armée américaine. Elles ont ensuite été reprises par des universitaires qui ont souhaité échanger des données. Les américains ont ainsi créé un réseau informatique reliant les premiers ordinateurs. À cette époque, seuls des "gentils" pouvaient communiquer avec d'autres "gentils", il n'y avait pas lieu de penser à la sécurité.
C'est pour cela que le protocole HTTP n'est pas sécurisé. A l'origine on n'avait pas encore pensé au fait que des personnes malintentionnées pouvaient avoir accès aux informations échangées ou pouvaient interférer dans la communication entre deux entités.

Si on est en train de chercher la page de l'office du tourisme de notre prochaine escale, cacher cette "conversation" entre notre navigateur et notre moteur de recherche préféré n'est a priori pas essentiel. En revanche, il serait judicieux que ce soit le cas lorsque l'on communiquera nos informations bancaires pour acheter notre billet. Autant éviter que quelqu'un les récupère pour les utiliser par la suite. De manière générale, il est nécessaire de protéger ses informations sensibles lorsqu'on les communique sur internet et ce pour plusieurs raisons. Si l'on doit les communiquer à un site (un service) en particulier. on aimerait être sûr de s'adresser à la bonne entité. On aimerait également s'assurer que les informations ne seront pas modifiées en cours de route pendant la communication, tant de notre côté que du côté du service. Le protocole HTTP ne garantit pas cela.

Heureusement, et sans le savoir, nous utilisons tous au quotidien la version sécurisée du protocole HTTP, le HTTPS (merci à Firefox, Chrome. Safari et Internet Explorer !). Il permet de garantir à la fois la confidentialité et l‘intégrité des données échangées et permet à l'utilisateur de vérifier l‘identité du serveur web avec lequel il échange.


Les entités de certification


Au moment de saisir son numéro de carte bancaire pour acheter des billets de train Montélimar-Poitiers, Chip a comme un doute : comment peut-elle savoir que le site auquel elle a affaire est bien le bon ? Chip se met donc en tête de vérifier qu'elle ne va pas envoyer ses coordonnées bancaires à des inconnus.

Premier test : visuellement Chip a bien l'impression d'être sur la bonne page d'accueil du bon site : l'image, la police de caractère et les emplacements des divers éléments sont identiques à d'habitude. C'est donc qu'on est bien sur le site de la SNCF ? Mais alors comment se fait-il que la page qui se trouve sous ce lien ressemble à s'y méprendre à une vraie page de réservation SNCF alors qu'elle se trouve sur un blog de sécurité informatique ?
Heureusement, depuis qu'elle a entendu parler du phishing, Chip fait attention et vérifie toujours l'adresse du site sur lequel elle se trouve dans la barre d'adresse de son navigateur. Si l'adresse du site est bonne, alors elle peut saisir ses coordonnées sans risque, et sinon elle doit passer son chemin, même si on jurerait que la page est authentique.

Mais Chip doute encore : si l'adresse est bonne, cela veut-il dire qu'elle est connectée au bon site ? Après tout Chip n'a aucune idée de la manière dont la page lui a été transmise. Cette page se trouve à l'origine dans une base de données (un data center) d'Île-de-France et doit passer dans le réseau Internet pour arriver à son propre ordinateur. Une chose est sûre. c'est qu'il y a forcément eu des intermédiaires pour transmettre la communication sur près de 600 kilomètres. Comment s'assurer qu'une autre page ne se fait pas passer pour la page de la SNCF ?



C'est à ce moment là qu'interviennent les autorités de certification. Une autorité de certification est une entité connue en laquelle le navigateur de l'utilisateur a confiance et qui se charge, moyennant, ou non, finance, de fournir des preuves d'identité aux sites qui en font la demande.
Ainsi le navigateur de Chip connaît par exemple la signature de l'autorité Geotrust. Lorsque la SNCF envoie à Chip sa page de paiement, elle y joint l'équivalent d'un mot signé fourni par Geotrust qui dit en substance "ceci est bien le site voyages-sncf.com". Comme cette signature est impossible à contrefaire, il suffit de vérifier que le mot fourni par Geotrust dit exactement "ceci est bien le site voyages-sncf.com" et pas "ceci est bien le site voyage-sncf.com" (sans le 's' de 'voyages') ou encore "ceci est bien le site grosse- arnaque.com" et il n'y a plus de contrefaçons à craindre.



Dans la pratique on ne vérifie pas nous-même la signature, notre navigateur s'en charge automatiquement : lorsque le site est authentifié par une autorité de certification, c'est-à-dire lorsque le navigateur a reçu cette signature de la part de l'autorité de certification, un petit cadenas s'affiche à gauche de l'URL. Tu peux même vérifier ton navigateur à cette page, le cadenas devrait être présent (sinon, il y a un problème). Une fois qu'une autorité de certification a assuré à un navigateur utilisateur qu'il parlait bien au serveur et réciproquement, on dit que l'authentification mutuelle entre le navigateur et le serveur est assurée.

Chip est donc rassurée et peut envoyer ses informations bancaires.

Oui mais...

Et si des entités malhonnêtes essayaient quand même de lire le numéro de carte bancaire qu'elle vient d'envoyer ? Après tout. Phish est partout !

Assurer la confidentialité et l'intégrité : le travail de la cryptologie 


Le protocole HTTPS est censé garantir la confidentialité et l'intégrité des données échangées. Cette garantie repose sur l'utilisation d'outils particuliers dont on entend de plus en plus parler ces derniers temps dans l'actualité : le chiffrement et les fonctions de hachage.

Une fois que l'authentification mutuelle entre le navigateur de Chip et le serveur de la SNCF est garantie grâce à l'intervention de l'entité de certification, ceux-ci vont s'échanger une clef de chiffrement et une clef pour la fonction de hachage qu'ils seront les seuls à se partager. Sans entrer dans les détails techniques, on peut être sûrs que cet échange de clefs a bien lieu entre les deux entités concernées (et personne d'autre) parce que le protocole HTTPS fait intervenir un autre protocole dans son fonctionnement : TLS, qui est ce qu'on appelle un protocole de bout-en-bout (ou end-to-end). TLS garantit un échange sécurisé des clefs évoquées plus haut.
L'utilité desdites clefs va être détaillée plus loin, pour faire simple, voyez les comme de très grands nombres.

Chip aimerait que Phish évite d'intercepter des informations qui ne le regardent absolument pas
En effet, maintenant que Chip est sûre d'être bien connectée au site de la SNCF, elle veut être sûre que personne n'intercepte ses données pour les lire. C'est ce qu'on appelle en sécurité, la confidentialité de la communication.
Il se trouve que le chiffrement permet de rendre toute donnée chiffrée "incompréhensible" aux yeux de tous. Le navigateur de Chip va utiliser la clef de chiffrement qu'il partage avec le serveur de la SNCF pour chiffrer sa communication. Ainsi, si Phish interceptait le message comportant les coordonnées bancaires de Chip, il ne verrait qu'un goubligoulba incompréhensible qui ne donne absolument aucune information sur les coordonnées bancaires que Chip vient de transmettre. Le serveur va lui aussi recevoir cette suite de caractères incompréhensibles, mais lui possède la clef de chiffrement ! Il va donc pouvoir déchiffrer le message et lire les coordonnées bancaires de Chip.
Dans le domaine de la cryptologie, cette méthode de chiffrement est appelée chiffrement symétrique puisque le serveur de la SNCF et le navigateur possèdent et utilisent tous les deux la même clef (symétrique donc) pour chiffrer et déchiffrer des messages.

Phish pourrait aussi s'amuser à changer complètement le message que Chip souhaite faire passer.


Reste que Chip n'aimerait pas non plus que Phish change son message en cours de route. Par exemple, il serait fâcheux que Phish arrive à changer le montant qu'elle doit à la SNCF pour payer son billet. Pour éviter cela, le protocole HTTPS garantit l'intégrité des données échangées entre deux parties, c'est à dire que si un message du navigateur de Chip est lu par le serveur de la SNCF, ce dernier peut être sûr qu'il s'agit bien du message original.
Grâce à la clef de hachage échangée juste après la phase d'authentification mutuelle, le navigateur et le serveur vont utiliser des fonctions de hachage sécurisées (HMAC). A quoi servent ces fonctions ? Eh bien elles prennent en entrée une clef de hachage et un message. Elles vont alors calculer à partir de la clef et du message une valeur bien spécifique. Vois ces valeurs comme des empreintes digitales : elles sont uniques et propres à chaque message. Ainsi, chaque fois qu'un message est envoyé, le navigateur ou le serveur vont le "signer" avec cette empreinte.
Quand le serveur de la SNCF reçoit un message de la part du navigateur de Chip, il s'attend également à recevoir son empreinte hachée. Il saura lui aussi calculer l'empreinte du message qu'il vient de recevoir puisqu'il possède la clef qui a servi à la générer également. En comparant l'empreinte du message qu'il a calculée avec l'empreinte qu'il a reçu, il pourra s'assurer, si ce sont bien les mêmes, que le message provient bien du navigateur de Chip.
Si Phish voulait envoyer un message à la place de Chip, il devrait l'accompagner de l'empreinte correspondante. Mais pour calculer celle-ci, il devrait posséder la clef que se sont échangée le navigateur de Chip et le serveur de la SNCF. Ce qui n'est pas le cas.

Chip peut ainsi envoyer en toute quiétude ses coordonnées bancaires au site de la SNCF.

Le HTTPS ne fait pas tout 


Le protocole HTTPS a l'air formidable : il permet de s'assurer que l'on communique bien avec le site voulu, que personne ne puisse écouter cette communication et qu'on ne puisse pas interférer dans celle-ci ! Alors pourquoi tous les sites ne l'utilisent pas ?

Grâce au HTTPS, Chip et Chip peuvent communiquer sans craindre que Phish ne les embête.


Chip a appris à se méfier dès lors qu'on lui dit qu'un outil est parfait. Et ça tombe bien car en sécurité informatique tout est affaire de compromis.

La première limite du HTTPS concerne l'autorité de certification. Pour s'assurer qu'elle parle bien à la SNCF, Chip doit faire confiance à l'entreprise Geotrust qui garantit l'identité de la SNCF. Le protocole HTTPS n'est pas magique, il se contente de déplacer la confiance de l'utilisateur vers un petit nombre d'entités. Ces entités de confiance sont celles dont l'identité est connue du navigateur utilisé. On se rend bien compte que sans ces autorités de certification, difficile, voire impossible de garantir l'authentification mutuelle évoquée plus haut. Mais pour cela, il faut faire confiance aux entreprises qui agissent en tant qu'autorités de certification. Et ces entreprises sont, dans la plupart des cas, de droit privé. Le HTTPS ne remet pas en question la confiance accordée à ces entreprises.
De plus une autorité de certification propose un service payant, un certificat Geotrust coûte par exemple aux alentours de 250€ par an pour un service de base. Tous les sites n'auront pas intérêt à acheter une prestation qui peut s'avérer onéreuse. Heureusement, on peut souligner des initiatives comme "Let'sEncrypt", qui propose depuis 2015 une autorité de certification gratuite et libre pour les sites ne souhaitant pas dépendre d'autorités de certification privées.

La deuxième limite est liée à ce qu'apporte HTTPS : ce qui est garanti c'est uniquement que le site auquel l'utilisateur accède est bien celui qu'il prétend être. Mais un ordinateur est stupide, il peut confirmer à Chip qu'elle est bien sur le site authentifié voyagesncf.com. Si Chip voulait en fait aller sur voyages-sncf.com (avec un tiret), le navigateur n'en a aucune idée. Il convient donc à l'utilisateur de bien vérifier que l'URL du site auquel il accède est bien l'URL du site auquel il voulait accéder. Le HTTPS ne prête pas des pouvoirs de divination au navigateur.
Il arrive également que les certificats des sites auxquels un utilisateur cherche à accéder ne soient pas valides. Cela peut arriver si par exemple, le certificat a expiré ou qu'il n'est pas émis par une autorité de certification reconnue. Le navigateur préviendra alors l'utilisateur du problème et lui proposera tout de même d'accéder au site.

Mozilla signale ici que la connexion au site n'est pas certifiée.


Dans un tel cas il vaut mieux refuser. Sauf si éventuellement, on connait le site et que l'on sait qu'il gère mal ses certificats, mais nous ne le conseillons pas sur ce blog.

Enfin on trouve régulièrement des failles dans HTTPS. Les chercheurs spécialisés en sécurité informatique trouvent plusieurs attaques chaque année, attaques qui pourraient potentiellement être mises en oeuvre par des individus malveillants. Les origines de ces failles sont multiples et très difficiles à prévoir car elles ont lieu à différents niveaux.
Elles sont cependant, en général, très faciles à corriger une fois détectées (les spécialistes de la sécurité informatique qui les trouvent fournissent dans la plupart des cas la solution pour les corriger). Mais pour bénéficier de ces correctifs, il est primordial d'avoir un navigateur à jour, puisque c'est lors de la mise à jour que le "pansement" qui permet de "réparer" le dysfonctionnement détecté est envoyé. Un utilisateur qui bloquerait ces mises à jour se rendrait vulnérable aux attaques sur le HTTPS.
Mais il rendrait également vulnérables les autres internautes ! Les serveurs, pour s'assurer qu'un maximum d'utilisateurs accèdent à leurs sites et services, acceptent également les utilisateurs possédant des versions obsolètes de navigateurs. Plus ces utilisateurs sont nombreux, plus les sites sont obligés de continuer à les autoriser (dans le jargon, on parle de rétrocompatibilité). Cela fait prendre des risques à tous, car un attaquant peut alors parfois forcer un utilisateur à jour à utiliser une version ancienne et corrompue d'HTTPS.
Evidemment, les mises à jour ne doivent pas se faire que du côté des particuliers, les serveurs sont aussi tenus de les faire. Et tout le monde peut tester les sites auxquels il se connecte pour savoir s'ils ne sont pas vulnérables ! Par exemple, ce site permet à quiconque de s'assurer de la sécurité du site dont on lui donne l'URL.

Qu'attends-tu pour tester ta banque ?


Les VIII commandements pour éviter de se faire avoir



  • L'URL des sites sur lesquels tu vas, tu vérifieras.
  • Ta confiance à n'importe quel site tu n'accorderas point.
  • La connexion HTTPS tu chériras.
  • Le petit cadenas à gauche de ta barre d'adresse tu repéreras.
  • Au moindre "je comprends les risques et j'ajoute une exception" tu fuiras.
  • Ton navigateur à jour tu tiendras.
  • La mise à jour des sites sensibles auxquels tu te connectes, tu testeras.
  • Comme Chip, méfiant tu seras.

Aucun commentaire:

Enregistrer un commentaire