Quelle est la différence entre HTTP et HTTPS ?

Quelle est la différence entre HTTP et HTTPS ?

Avez-vous déjà tenté d’accéder à une page web avant d’être interrompu par votre navigateur qui vous indique que ce site n’est pas sécurisé ?

Mais qu’est-ce que cela signifie ? En quelques mots, cela signifie que lorsque vous échangez des données avec un site Internet, elles transitent en clair et peuvent être interceptées à tout moment. Le risque est faible lorsque vous visitez un site de recettes de cuisine ou un autre site avec peu de données confidentielles. Mais imaginez un instant que vous vous connectiez à votre banque en ligne et qu’une personne mal intentionnée puisse, le plus simplement du monde, intercepter vos échanges d’identifiants, de mots de passe, de numéro de compte, etc.

À quoi ressemble un échange de données en HTTP ?

Le protocole de transfert de données HTTP (HyperText Transfer Protocol) est le protocole utilisé pour demander et recevoir un contenu (media, texte, video, etc.).

Dans le cas d’un transfert HTTP, le fonctionnement est direct :

  1. Le client (internaute) se connecte au serveur (site internet) via http
  2. Tous deux échangent des informations de manières non chiffrées.

Une personne mal intentionnée est alors en mesure d’intercepter des données, en clair, directement à l’aide d’un analyseur de paquets, aussi appelé Sniffer.

Quelle est la différence avec un échange HTTPS ?

Dans le cas d’une connexion sécurisée HTTPS (HyperText Transfer Protocol Secure), un troisième acteur (en plus du pirate) entre en jeu : l’autorité certifiante qui va se porter garante de la sécurisation des échanges entre le serveur et le client.

La chronologie d’un échange d’information est alors nettement plus complexe.

Délivrance d’un certificat au serveur

L’autorité certifiante délivre un certificat au serveur.

Le certificat est accompagné d’une clé publique et d’une clé privée. Les clés se présentent sous la forme de suite de caractères qui, associées à un message par exemple, vont permettre de le crypter ou le décrypter.

De manière très simplifiée et schématique, on pourrait dire qu’une clé de valeur 1 décalerait de un caractère dans l’alphabet votre message. Si l’utilisateur envoie le message « coucou » chiffré avec une clé 1, le message deviendrait alors « dpvdpv ». C’est évidemment loin d’être aussi simple mais voici pour l’idée de clé.

Dans le cas du certificat dont il est question, il existe une clé publique qui est mise à disposition de tous pour pouvoir chiffrer un message vers le serveur et une clé privée qui permettra de déchiffrer les messages reçus.

L’échange d’information en HTTPS

  1. Le client (vous) se connecte cette fois-ci via le protocole HTTPS (HyperText Transfer Protocol Secure) au serveur (site internet)
  2. Au lieu d’échanger directement des informations, le serveur envoie au navigateur du client le couple certificat SSL (Secure Socket Layer) / clé publique.
  3. Le navigateur du client vérifie l’authenticité du certificat auprès de l’autorité certifiante
  4. L’Autorité certifiante valide l’authenticité du certificat
  5. Si le certificat est valide, le navigateur du client va générer une nouvelle clé : la clé de session, qui se génère à l’aide de la clé publique du serveur.
  6. Le client envoie la clé de session au serveur
  7. Le serveur est en mesure de décrypter la clé de session grâce à sa propre clé privée

Le client et le serveur disposent alors tous les deux d’une clé de session commune qu’ils sont les seuls à détenir. Ceci permet un échange d’informations chiffrées que seule la clé de session peut permettre de déchiffrer. Or, personne d’autre ne dispose de cette clé de session.

Ainsi, même si une personne mal intentionnée intercepte les données échangées, elle n’interceptera que les données chiffrées sans avoir la clé permettant le déchiffrage.