Le HTTPS, qu’est-ce que c’est et à quoi ça sert ?

Vous avez déjà certainement remarqué que le HTTPS vous permet d’avoir un joli petit cadenas à côté de la barre d’adresse de votre navigateur vous indiquant que la connexion est “sécurisée”. Mais que veut vraiment dire “connexion sécurisée” ? Cela veut-il dire que vous pouvez avoir une confiance absolue envers n’importe quel site arborant fièrement un cadenas aux côtés de son adresse ? Non, certainement pas. Nous allons voir pourquoi en expliquant ce qu’implique et n’implique pas une connexion HTTPS.

Introduction

HTTPS signifie HyperText Transfer Protocol Secure, c’est tout simplement le protocole HTTP¹ - utilisé entres autres depuis la fin des années 1990 dans les communications entre site web et navigateurs - auquel on ajoute une couche de “sécurité”. Cette couche est portée par le protocole TLS (Transport Layer Security) et mise en œuvre à l’aide de certificats. Nous n’allons pas expliquer ici en détail le fonctionnement des certificats ni comment ils sont délivrés, un article y sera dédié plus tard, néanmoins quelques informations concernant leur contenu ainsi que quelques éléments de cryptographie (ne fuyez pas !) sont nécessaires pour comprendre le fonctionnement des connexions HTTPS.

Le certificat

Pour simplifier à l’extrême, un certificat est une carte d’identité virtuelle délivrée par un organisme de confiance. Il embarque tout un tas d’informations nécessaires à l’identification et à l’authentification (d’un site web dans notre cas²). Nous nous attarderons ici uniquement sur quelques uns des éléments présents dans un certificat : le nom du ou des site(s) web pour lequel il est valide et la clé publique.

Le Nom Courant ou Common Name (CN), permet d’associer un certificat à un nom de domaine. On peut voir dans la capture ci-dessus³ que le certificat est prévu pour plusieurs noms de domaines (Noms alternatifs du sujet).

Lorsqu’il est délivré par une autorité de confiance, celle-ci s’assure que le demandeur du certificat est bien le propriétaire du site web. Cette étape permet de faire du certificat une preuve de l’identité du site en question. Pour reprendre l’analogie de la carte d’identité, lorsque vous faites une demande de délivrance de carte auprès de la préfecture, des preuves de votre identité (certificat de naissance, justificatif de domicile, etc) vous sont demandées. Sans cela, n’importe qui pourrait demander une carte d’identité à votre nom. Le principe est le même pour les certificats, l’autorité demande des preuves de possession du site. Nous n’expliquerons pas les méthodes possibles ici mais nous en parlerons dans l’article dédié aux certificats.

Si aucune valeur de ces champs ne correspond au nom du site web, le navigateur alertera alors l’utilisateur. Ça sera d’ailleurs le cas pour toute incohérence dans le certificat (date de validité dépassée, autorité de certification non reconnue…) :

Une question sous-jacente apparait : comment s’assurer que l’autorité ayant délivré le certificat ait effectué cette vérification correctement ? Il s’agit ici d’une question de confiance envers des autorités de certification reconnues par les navigateurs⁴ et dont les procédures ont été vérifiées (là encore, nous verrons ceci plus en détail dans l’article sur les certificats). Si l’on suit encore l’analogie de la carte d’identité, l’autorité de certification de confiance serait la préfecture (voir schéma ci-dessus).

Comme évoqué précédemment, si l’autorité ayant signé le certificat n’est pas reconnue, le navigateur vous invitera à ne pas continuer sur le site :

Le second élément capital ici est la clé publique. Comme promis, nous allons devoir aborder quelques notions essentielles et simples de cryptographie. Un message est chiffré (et non “crypté”⁵) à partir de ce qu’on appelle une clé. Cette clé prend simplement la forme d’une suite de caractères plus ou moins longue suivant l’algorithme de chiffrement utilisé et est passée dans diverses fonctions mathématiques que nous n’aborderons pas ici et qui dépendent de l’algorithme de chiffrement utilisé.

Prenons ici l’exemple d’Alice⁶ qui souhaite faire des achats sur Internet et qui doit transmettre ses informations bancaires au site web. Dans le premier cas, Alice achète ses chaussettes (si vous vous ennuyez vous pouvez tenter de répéter cette phrase à haute voix 5 fois de suite) sur un site web sans HTTPS. Dans cet exemple, quiconque se trouvant sur le réseau entre le navigateur et le site web peut intercepter et lire les coordonnées bancaires d’Alice. Dans le second cas, les messages étant chiffrés les coordonnées ne sont pas lisibles si elles sont interceptées :

Digression sur la cryptographie

Nous distinguerons deux types de chiffrement :

• Le chiffrement symétrique qui utilise une seule clé secrète utilisée à la fois pour chiffrer et déchiffrer les messages. Elle doit donc être connue de tous les participants à la “conversation”. L’avantage de ce type de chiffrement est sa rapidité, son désavantage principal est la problématique de l’échange de clé : une fois celle-ci générée, comment effectuer l’échanger de manière sûre ? En effet, si la clé est divulguée, la confidentialité des messages n’est plus assurée.

• Le chiffrement asymétrique qui utilise deux clés par utilisateur : une clé privée qui comme son nom l’indique doit rester connue seulement de l’utilisateur (le site web dans notre cas) et une clé publique qui elle, peut et doit être connue des interlocuteurs. Nous verrons ici deux cas d’utilisation : le chiffrement d’un message et la signature d’un message, le premier cas permet d’assurer la confidentialité de celui-ci et le second son authenticité (ainsi que la notion de non-répudiation qui empêche de pouvoir nier avoir envoyé un message signé).
  Lorsque l’on veut chiffrer un message, on utilise la clé publique du destinataire. Tout le monde peut chiffrer un message avec une clé publique, mais seul le possesseur de la clé privée associée peut le déchiffrer.
  Inversement, pour signer un message, on utilise la clé privée connue uniquement par son propriétaire et n’importe qui peut déchiffrer ce message avec la clé publique associée, mais seulement avec cette clé, ce qui permet de s’assurer que seul le possesseur de la clé privée a pu écrire ce message. En pratique, un utilisateur détient une paire de clé par type d’utilisation (chiffrement, signature, authentification…).

Dans le cas du HTTPS, la connexion va être chiffrée à partir de la clé publique présente dans le certificat du site web. De son côté, le navigateur va lui aussi générer un couple clé privée / clé publique pour communiquer avec le site web. Petite subtilité néanmoins : au début le navigateur connait seulement la clé publique du site web. Le site web, lui, ne sait rien du navigateur, ce dernier utilise donc la clé publique du site web pour lui envoyer de manière confidentielle les informations qui permettront ensuite au navigateur et au site web de calculer la même clé, et donc établir un canal sécurisé basé sur du chiffrement symétrique.
En effet, comme expliqué plus haut, le chiffrement symétrique est bien plus rapide que le chiffrement asymétrique (environ 1000 fois), le chiffrement asymétrique vient répondre à la problématique de l’échange de clé. Pour plus de détails techniques sur le protocole TLS, voir ici.

C’est bien gentil me direz-vous, mais on n’a toujours pas répondu aux questions du début ! Oui, mais malheureusement les notions expliquées ci-dessus sont nécessaires pour comprendre les limites.

Et donc, à quoi ça sert le HTTPS ?

Reprenons : lorsque nous arrivons sur un site web en HTTPS, le navigateur examine le certificat et vérifie l’identité du site web. Il utilise ensuite la clé publique contenue dans le certificat, - délivrée par une autorité de confiance - pour initier une connexion chiffrée avec le serveur. Vous suivez toujours ? Une fois la connexion chiffrée initiée, une clé de chiffrement symétrique est générée pour continuer les échanges.

Nous pouvons donc répondre à la question : le HTTPS, à quoi ça sert ? Le HTTPS sert à s’assurer de l’identité du site web et à garantir la confidentialité des échanges entre le serveur et le navigateur car seuls le navigateur et le site web connaissent la clé utilisée pour chiffrer les échanges.

Et là je vous vois venir encore : Quoi, tout ça pour ça ? Tu n’aurais pas pu nous le dire tout de suite plutôt que de nous bassiner avec tes histoires de cryptographie ?
Eh bien comme je l’ai dit quelques lignes plus haut, les notions présentées succinctement ici sont nécessaires pour comprendre comment l’identité est vérifiée, comment la confidentialité est assurée et surtout ce que le HTTPS ne garantit pas !

Les limites

Lorsque je parle de limites, il ne s’agit pas de dire que le HTTPS n’est pas un protocole fiable, seulement de bien comprendre ce qui n’est pas de son ressort.

Comme nous l’avons vu, HTTPS garantie la confidentialité de la communication entre le navigateur et le serveur. Attention néanmoins, certaines entreprises et administrations configurent les navigateurs des postes de travail pour permettre aux outils de supervision de déchiffrer les communications sortantes. Dans ce cas, les données sont donc lisibles par l’entreprise⁷.

De plus, il faut bien comprendre que seule la communication entre le navigateur et le site web est confidentielle. Cela ne donne aucune garantie sur le traitement des informations envoyées une fois sur le site web. Cela ne donne aucune information sur comment elles sont stockées ni à qui elles sont envoyées, même si le récent Règlement Général sur la Protection des Données (RGPD) vient poser des conditions légales un peu plus strictes qu’auparavant sur ces sujets. Un article à ce sujet verra le jour prochainement, en attendant je vous invite à regarder cette video de Cookie Connecté (et toutes ses autres vidéos !).

Il faut aussi noter qu’un site malveillant peut tout à fait posséder un certificat valide. Il est facile de se faire piéger à cause d’une adresse ressemblant à une adresse connue. On peut par exemple avoir le nom d’un site connue dans le sous domaine d’un site malveillant (par exemple netflix.toto.com n’appartient pas à neflix.com mais à toto.com). Il arrive aussi de voir des tentatives d’usurpation avec des caractères spéciaux dans le nom de domaine pouvant tromper un utilisateur peu attentif, voir même être interprétés comme des caractères classiques trompant ainsi directement le navigateur⁸ même si les navigateurs récents sont censés détecter ce genre de subtilité.

Enfin, comme tout protocole, des vulnérabilités ont été découvertes sur TLS, notamment Hearthbleed en 2014 permettant de récupérer les clés privées utilisées pour chiffrer les conversations. Elle a été corrigée depuis mais il est possible qu’elle ait été utilisée par la NSA (qui dément) pendant plusieurs années pour déchiffrer les connexions⁹

Encore une fois, il ne s’agit pas de vous rendre parano, mais de bien comprendre dans quel périmètre agit la sécurité sur protocole HTTPS.

Il faut tout de même noter que de façon relativement inédite, et pour essayer de se prémunir contre les attaques après les nombreuses défaites des versions précédentes, TLS 1.3 a été construit très progressivement avec une consultation permanente auprès des spécialistes de la sécurité informatique, venant à la fois du milieu académique et industriel, et n’a été standardisé qu’une fois que tout le monde était satisfait.

Conclusion

Résumons ce que nous avons vu depuis le début : la couche de sécurité du HTTPS est porté par le certificat associé au site web. Le certificat peut être vu commet une carte d’identité virtuelle, contenant des informations sur l’identité du site web qui ont été vérifiées par l’autorité de certification l’ayant délivrée. Tout cela permet de prouver l’identité du site web, c’est à dire de s’assurer que nous sommes bien sur le site désiré (attention néanmoins aux adresses ressemblant comme vu ci-dessus).
La clé publique contenue dans ce certificat permet ensuite d’initier une connexion chiffrée entre le navigateur et le serveur, empêchant ainsi la divulgation d’informations potentiellement sensibles (mots de passe, numéro de carte bancaire…). Néanmoins, le protocole ne garantit rien sur le traitement des informations une fois sur le serveur.

Comprenez donc bien que le HTTPS est absolument nécessaire dès lors que la moindre information personnelle est envoyée vers un site web. Permettant aussi de s’assurer de l’identité du site, il serait donc bienvenu que tous les sites web disposent d’un certificat, d’autant plus qu’un protocole (ACME) permet d’en obtenir facilement et rapidement.

Merci à Angèle (docteure en cryptographie) pour les précisions apportées et à Romain et Christophe pour la relecture.