Décrire de manière détaillée le protocole HTTPS

Lors d’une communication, on peut récupérer des données et des clés en utilisant la technique dite de l’attaque de l'homme du milieu.

Cette attaque est notamment possible dans une communication qui utilise le protocole HTTP car l’échange est réalisé sans authentification.

Cette attaque est également facilement réalisable dans une communication qui utilise l’algorithme d’échange de clés Diffie-Hellman, lorsque l'échange est réalisé sans authentification.

Attaque de l’homme du milieu
lors d’un échange de clés Diffie-Hellman

Chiffrer une communication ne sert donc à rien s’il n’y a pas un moyen d’authentifier chaque participant.

Sur le web, l’authentification est assurée par des certificats délivrés par des tiers de confiance.

Avant de procéder à un quelconque échange de clés, on procède d’abord à une authentification : Bob veut authentifier sa communication avec Alice pour être certain de communiquer avec Alice. Il va donc lui demander un certificat qui a été émis par un tiers de confiance nommé « Tiers ».

Voici le principe de l’authentification via un certificat.

1. Alice doit créer un certificat, elle envoie sa clé publique  à Tiers.
   Celui-ci chiffre alors la clé publique d’Alice avec sa clé privée .
   Soit c = , qui est un certificat.
2. Lorsque Bob souhaite communiquer avec Alice, celle-ci lui fournit alors sa clé publique  et son certificat c.
3. Bob récupère la clé publique du Tiers .
4. Bob calcule alors (c) qui doit être égal à  
   (car  doit donner ).
5. Si c’est le cas, on peut alors commencer une communication sécurisée avec l’échange de clés Diffie-Hellman.

Les tiers de confiance émettent des certificats qui répondent à certains formats. L’Union internationale des télécommunications (UIT) a choisi la norme X.509 pour spécifier les formats des certificats à clé publique.

D’après cette norme, un certificat à clé publique doit contenir :

• la version du certificat ;
• le numéro de série du certificat ;
• l’algorithme de signature du certificat ;
• le nom de l’émetteur du certificat (autorité de certification) ;
• une date de début et une date de fin de validité du certificat ;
• l'objet d’utilisation du certificat ;
• des informations sur la clé publique
  (algorithme de chiffrement et la clé publique) ;
• la signature de l’émetteur du certificat ;
• l’identifiant unique du signataire (optionnel).

Exemple de certificat du site www.education.gouv.fr

Le protocole HTTP permet de décoder le contenu d’une trame et donc de retrouver des informations échangées entre deux entités (nom d’utilisateurs, mots de passe, etc.).

Il a fallu rajouter un protocole de chiffrage car le protocole HTTP a un défaut majeur : les paquets d’informations échangés peuvent être facilement interceptés et lus avec un logiciel libre.

Le protocole TLS permet de garantir :

• l'authentification du serveur avec les certificats signés par une autorité de certification ;
• la confidentialité du message avec un chiffrement symétrique ;
• l'intégrité du message avec un code d’authentification de message ;
• l'échange d'une clé de session avec un chiffrement asymétrique de type RSA ou Diffie-Hellman.

1. Le client initie la connexion avec une requête « Hello » en clair avec ce qu’il peut utiliser comme algorithmes de cryptographie.
2. Le serveur répond « Hello » avec son certificat X.509 qui contient sa clé publique signée par le tiers de confiance.
3. Le client vérifie la signature du certificat avec la clé publique du tiers de confiance, il vérifie aussi la date de validité. Si l’une des informations n’est pas bonne, le navigateur affichera un message d’erreur.
4. Si tout est bon, le certificat est validé, le client peut échanger une clé de chiffrement symétrique en utilisant par exemple un algorithme de chiffrement asymétrique de type Diffie-Hellman ou RSA.
   Cette clé se nomme la clé de session.
5. Le client et le serveur peuvent échanger des données chiffrées via le protocole HTTPS.