Comment le HTTPS fonctionne

Vous êtes-vous déjà demandé pourquoi une icône représentant un verrou vert apparaît dans la barre d'adresse de votre navigateur ? Et pourquoi est-ce important ?

Apprenez à connaître le protocole HTTPS et pourquoi il est essentiel pour votre vie privée.

Pourquoi a-t'on besoin du HTTPS ?

Pour 3 raisons :

• Confidentialité,
• Intégrité,
• Identification.

La Confidentialité

Pour commencer par ce premier item, lorsque vous vous connectez à un site Web, il y a donc un échange d'informations entre le serveur qui héberge ce site et votre poste.

Le flux de l'information peut contenir des informations sensibles (mots de passes, données bancaires, ... ) et chiffrer ce flux devient alors essentiel.

Afin de le chiffrer, un certificat SSL/TLS est alors nécessaire pour établir une connexion sécurisée entre le serveur du site Web et votre poste. Il faut également songer à modifier le service Web afin de rediriger le trafic Web du port 80 (HTTP) vers le port 443 (HTTPS).

Le petit cadenas (il n'est plus vert sur Chrome) vous permet de savoir si vous êtes bien sur une page en https.

L'Intégrité

Ensuite, le protocole HTTP (non sécurisé) est celui qui est le plus prisé pour les attaques informatiques de type "man-in-the-middle" (l'homme au milieu ), car en plus d'intercepter les communications, il peut également les modifier.

Lors d'une connexion en https, l'intégrité du certificat est vérifiée afin de valider que la source du site ne soit pas compromise.

L'Identification

Enfin, l'identification va de paire avec l'intégrité, lorsque le certificat SSL est généré, il demande au fournisseur du nom de domaines, les informations nécessaires à sa création.

Les navigateurs vérifient également l'authenticité des certificats SSL, ainsi que leur validité.

Les clés

Le protocole HTTPS a besoin d'un moyen de garantir la confidentialité, l'intégrité et l'identification sur le Web et ce mécanisme s'appelle le chiffrement.

Parlons des deux types d’algorithmes de chiffrement.

Commençons par l'algorithme à clé symétrique, dans ce scénario, il existe une seule clé pour chiffrer et déchiffrer un message.

Le processus de chiffrement consiste à placer un message dans une boîte et à la verrouiller avec une clé, seule la personne qui possède une copie de la clé peut ouvrir la boîte et lire le message.

Cela garantit que la boîte ne pourra pas être ouverte tant qu'elle n'aura pas atteint la personne avec la bonne clé.

Le problème avec les clés symétriques est qu’elles sont difficiles à partager, cela nous amène aux clés asymétriques.

La principale différence avec les clés symétriques est que vous avez 2 clés, une clé est publique, l'autre est privée. Elles sont jumelées et travaillent ensemble.

En d'autres termes, le navigateur met le message dans une boîte et le verrouille avec la clé publique, seule la clé privée peut ouvrir une boîte verrouillée avec des clés publiques.

C'est efficace, non seulement pour la confidentialité, mais aussi pour l'identification, car nous savons que seul le propriétaire des 2 clés peut ouvrir le message.

Nous verrons ensuite comment les clés symétriques et asymétriques jouent un rôle lorsque nous nous connectons à un site avec SSL.

The Handshake (La poignée de main)

Lorsque vous vous êtes connectés sur cette page, le petit cadenas (vert ou pas !) c'est affiché dans votre navigateur.

Comment est-ce arrivé?

Votre navigateur a communiqué avec mon serveur, où cette page est hébergée, et ils ont tous deux établi une connexion sécurisée pour la transmission des données. Mais avant tout, ils devaient se mettre d’accord sur la manière de communiquer en toute sécurité.

Si la négociation échoue, votre navigateur vous le fait savoir en affichant une erreur ou un avertissement. Si un accord est conclu, votre navigateur affiche un cadenas sur la barre d'adresse.

Ce processus, la négociation entre un navigateur et un serveur, est appelé "The Handshake".

Cela se décompose en plusieurs étapes :

• Le navigateur envoie une liste de versions de certificats SSL / TLS et d'algorithmes de chiffrement qu'il peut utiliser avec le serveur,
• Le serveur choisit la meilleure version SSL / TLS et le meilleur algorithme de chiffrement parmi ceux que le navigateur a envoyés et en fonction de la configuration du serveur,
• Le navigateur vérifie le certificat du serveur pour s'assurer qu'il soit légitime,
• Le navigateur génère ensuite une "clé principale" afin que lui et le serveur puissent l'utiliser tous les deux plus tard, lorsque qu'ils vont générer une clé unique,
• Le navigateur chiffre cette clé pré-maîtresse avec la clé publique du serveur puis la lui envoie,
• Le serveur utilise sa clé privée pour déchiffrer la clé pré-maître envoyée par le navigateur,
• Ils génèrent tous deux le même "secret partagé" qu'ils vont utiliser comme clé symétrique,
• Désormais, toutes les données échangées entre le navigateur et le serveur sont désormais sécurisées pour le reste de la session.

Les différences entre HTTPS, SSL et TLS

Il est facile de confondre ces termes et de les utiliser indifféremment.

HTTPS est la version sécurisée de HTTP: "HyperText Transfer Protocol". HTTP est le protocole utilisé par votre navigateur et vos serveurs Web pour communiquer et échanger des informations.

Lorsque cet échange de données est chiffré avec SSL / TLS, nous l'appelons HTTPS. Le "S" signifie "sécurisé".

SSL signifie "Secure Sockets Layer". Un protocole créé par Netscape. SSL est un dinosaure selon les normes Internet. La première version n'a jamais été publiée et la version 2 lancée avec le navigateur Netscape 1.1 en 1995.

Plus tard cette année-là, Netscape a publié la version 3, car la version 2 présentait des problèmes de sécurité majeurs. Netscape a ensuite donné le contrôle du protocole SSL à l'IETF: Internet Engineering Task Force.

Avant la fin de 1999, l’IETF publiait la version 1.0 de TLS (qui était vraiment SSL 3.1). SSL a été renommé TLS: "Transport Layer Security".

TLS 1.0 a décollé et la version 1.1 est sortie en 2006. Quelques années plus tard, en 2008, TLS 1.2 a été publié pour corriger quelques failles de sécurité.

Cependant, ce n'est qu'en 2013 que les navigateurs commencent à rattraper leur retard et à prendre en charge TLS 1.2. Pour ajouter à la confusion, SSL 3.0 a été officiellement déconseillé en 2015.

Les Autorités de certification

Une autorité de certification est une organisation tierce dont les objectifs principaux sont:

1. Délivrance de certificats,

2. Confirmation de l'identité du propriétaire du certificat,

3. Fournir la preuve de la validité du certificat.

Vous avez peut-être entendu parler de Symantec, Comodo ou Let's Encrypt, entre autres.

Devenir CA (autorité de certification) est une tâche intense liée aux exigences de sécurité et aux audits. Vous devez être digne de confiance pour être accepté dans un "rootstore".

Un rootstore est une base de données d'autorités de certification approuvées. Apple, Windows et Mozilla exécutent leurs propres rootstore qu’ils pré-installent sur votre ordinateur ou votre appareil.

Il existe 3 types de certificats :

• Domaine validé. Le certificat ne fait que vérifier le nom de domaine et rien d’autre. Vous avez probablement besoin de celui-ci,
• Organisation validée. Le certificat nécessite la validation et la vérification manuelle de l'organisation derrière le certificat,
• Validation étendue. Le certificat nécessite une vérification exhaustive de l'entreprise.

Tous les certificats valides entraînent l'affichage d'un badge sécurisé dans la barre du navigateur. Les certificats EV (Validation étendue) affichent généralement également le nom de la société.

Comment les certificats sont-ils validés ?

Lorsqu'une autorité de certification émet un certificat, elle signe le certificat avec son certificat racine  (root) préinstallé dans le rootstore. La plupart du temps, il s'agit d'un certificat intermédiaire signé avec un certificat racine.

Mais pourquoi utiliser une autorité de certification quand vous pouvez auto-signer vos certificats ?

Un certificat auto-signé fournit le même niveau de chiffrement que celui généré par une autorité, presque tous les navigateurs vérifient que le certificat est émis par une autorité de confiance. En tant que tels, les visiteurs sont avertis que le certificat ne peut pas être approuvé.

Les certificats auto-signés peuvent être utiles pour les tests et les intranets, mais évitez de les utiliser sur des sites publics. Les certificats auto-signés peuvent être falsifiés.

Un certificat de confiance indique: "Faites-moi confiance, une autorité m'a vérifié".