Protocole d’établissement de la liaison TLS

Le protocole TLS ( Transport Layer Security ) Est responsable de l’authentification et de l’échange de clés nécessaires pour établir ou reprendre des sessions sécurisées. Lors de l’établissement d’une session sécurisée, le protocole Handshake gère les éléments suivants :

• Négociation de suite de chiffrement
• Authentification du serveur et éventuellement du client
• Échange d’informations sur les clés de session.

Négociation de la suite de chiffrement

Le client et le serveur entrent en contact et choisissent la suite de chiffrement qui sera utilisée tout au long de leur échange de messages.

Authentification

Dans TLS, un serveur prouve son identité au client. Le client peut également devoir prouver son identité au serveur. PKI, l’utilisation de paires de clés publiques/privées, est la base de cette authentification. La méthode exacte utilisée pour l’authentification est déterminée par la suite de chiffrement négociée.

Échange de clés

Le client et le serveur échangent des nombres aléatoires et un numéro spécial appelé secret prémaître. Ces nombres sont combinés à des données supplémentaires permettant au client et au serveur de créer leur secret partagé, appelé secret principal. Le secret principal est utilisé par le client et le serveur pour générer le secret MAC d’écriture, qui est la clé de session utilisée pour le hachage, et la clé d’écriture, qui est la clé de session utilisée pour le chiffrement.

Établissement d’une session sécurisée à l’aide de TLS

Le protocole TLS Handshake implique les étapes suivantes :

1. Le client envoie un message « Client hello » au serveur, ainsi que la valeur aléatoire du client et les suites de chiffrement prises en charge.
2. Le serveur répond en envoyant un message « Server hello » au client, ainsi que la valeur aléatoire du serveur.
3. Le serveur envoie son certificat au client pour l’authentification et peut demander un certificat au client. Le serveur envoie le message « Serveur hello done ».
4. Si le serveur a demandé un certificat au client, le client l’envoie.
5. Le client crée un secret prémaître aléatoire et le chiffre avec la clé publique du certificat du serveur, en envoyant le secret prémaître chiffré au serveur.
6. Le serveur reçoit le secret prémaître. Le serveur et le client génèrent chacun le secret maître et les clés de session en fonction du secret prémaître.
7. Le client envoie une notification « Modifier la spécification de chiffrement » au serveur pour indiquer que le client commencera à utiliser les nouvelles clés de session pour le hachage et le chiffrement des messages. Le client envoie également le message « Client terminé ».
8. Le serveur reçoit « Modifier la spécification de chiffrement » et bascule son état de sécurité de la couche d’enregistrement vers le chiffrement symétrique à l’aide des clés de session. Le serveur envoie le message « Serveur terminé » au client.
9. Le client et le serveur peuvent désormais échanger des données d’application sur le canal sécurisé qu’ils ont établi. Tous les messages envoyés du client au serveur et du serveur au client sont chiffrés à l’aide de la clé de session.

Reprise d’une session sécurisée à l’aide de TLS

1. Le client envoie un message « Client hello » à l’aide de l’ID de session de la session à reprendre.

2. Le serveur vérifie dans son cache de session un ID de session correspondant. Si une correspondance est trouvée et que le serveur est en mesure de reprendre la session, il envoie un message « Serveur hello » avec l’ID de session.

   Notes

   Si une correspondance d’ID de session est introuvable, le serveur génère un nouvel ID de session et le client TLS et le serveur effectuent une négociation complète.

    

3. Le client et le serveur doivent échanger les messages « Modifier la spécification de chiffrement » et envoyer les messages « Client terminé » et « Serveur terminé ».

4. Le client et le serveur peuvent maintenant reprendre l’échange de données d’application via le canal sécurisé.