Le protocole HTTPS

On a vu en classe de Première le fonctionnement du protocole HTTP utilisé sur le Web pour communiquer. Ce protocole historique a deux défauts :

• les informations transitent en clair sur le réseau et donc peuvent être lues par un tiers.
• il est vulnérable à l'attaque de l'homme au milieu

Pour chiffrer les échanges et authentifier les participants sur le Web, c'est le protocole HTTPS qui est utilisé (pour Hypertext Transfer Protocol Secure). Il s'agit du protocole HTTP auquel on a ajouté une couche de cryptographie grâce au protocole TLS (Transport Layer Security, soit « sécurité de la couche de transport »), anciennement appelé SSL (Secure Sockets Layer, couche de sockets sécurisée).

Le protocole TLS permet initialement d'authentifier le serveur et de mettre en place une clé de chiffrement symétrique, appelée clé de session. Les échanges peuvent ensuite se poursuivre suivant le protocole HTTP en chiffrant les messages avec la clé de session :

Fonctionnement du protocole HTTPS

Étape 1 : Le client envoie un message (appelé Hello) au serveur pour demander une connexion sécurisée (il indique aussi les algorithmes cryptographiques qu'il peut utiliser)

Étape 2 : Le serveur envoie sa réponse contenant notamment sa clé publique et son certificat qui n'est autre que la signature de la clé publique par l'autorité de certification.

Étape 3 : Le client fait appel à l'autorité de certification pour vérifier le certificat grâce à la clé publique de l'autorité de certification comme indiqué dans le paragraphe précédent (en pratique, les navigateurs disposent des clés publiques des autorités de certification).

Étape 4 : Une fois le certificat validé, le client et le serveur utilisent un algorithme de chiffrement à clé publique (asymétrique) pour définir une clé de chiffrement partagée appelée clé de session :

• soit RSA : le client choisit une clé et la chiffre avec la clé publique du serveur avant de l'envoyer au serveur
• soit l'échange de la clé se fait selon l'algorithme de Diffie-Hellmann

Étape 5 : Le client et le serveur utilisent cette clé de session dans un chiffrement symétrique (par exemple AES), beaucoup plus rapide, pour poursuivre les échanges avec le protocole HTTP mais dans lequel les requêtes et les réponses sont chiffrées.

Dans le navigateur

Si la certification échoue à l'étape 3, alors le navigateur alerte l'utilisateur avec un écran similaire à celui-ci :

Crédit : Cepheus, Domaine public, via Wikimedia Commons

De plus, toujours à l'étape 3, le client vérifie également que le certificat est toujours valide. Si ce n'est pas le cas, le navigateur prévient l'utilisateur de l'expiration du certificat (le serveur est néanmoins authentifié) et on obtient des avertissements qui ressemblent à ceci :

Enfin, sachez qu'il est possible de consulter le certificat d'un serveur (auquel on est connecté en HTTPS) dans le navigateur en cliquant sur le cadenas situé à côté de la barre d'URL. Par exemple, si on cherche le certificat du site info-mounier.fr, le navigateur affiche cela :

Crédit : Image personnelle

On peut ainsi voir l'authorité qui certifie la connexion (DigiCert Inc) et comment la connexion a été chiffrée dans les détails techniques :

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bits, TLS 1.2

que l'on peut analyser rapidement :

• Le protocole TLS a été utilisé (dans sa version 1.2)
• Le sigle ECDHE, pour Elliptic Curve Diffie-Hellmann Ephemeral, indique que la clé de session a été échangée par le protocole de Diffie-Hellmann (dans une variante utilisant les courbes elliptiques comme problème mathématique sous-jacent).
• L'authentification est assurée par le protocole RSA.
• Le chiffrement symétrique, grâce à la clé de session, est assuré par l'algorithme AES128

Exercice

Bilan