Le protocole TLS de sécurisation des échanges numériques inclut un sous-protocole, baptisé TLS Handshake. Il a pour objectif de permettre au serveur et au client de s’authentifier entre eux, puis de négocier un algorithme de chiffrement et une clé cryptographique avant que l’application ne transmette les données. Son principe de fonctionnement, en détail.
Authentification TLS : zoom sur le protocole Handshake
Le protocole TLS est, au même titre que TCP/IP, une suite protocolaire client-serveur composée de quatre sous-protocoles. Le sous-protocole Handshake (qui signifie poignée de main en anglais) de TLS a pour objectifs de négociations :
- Les algorithmes de chiffrement (symétriques et asymétriques)
- Les longueurs de clés symétriques
- Les algorithmes de signature (HMAC)
- La fédération d’identités
- Et, optionnellement, l’authentification du client par le serveur
Client et serveur choisissent les algorithmes les plus puissants qui sont en commun. Si aucun algorithme n’est trouvé, la communication est directement coupée (protocole Alert). La négociation des clés se fait de la même manière.
L’authentification est effectuée avec des certificats X.509.
Les échanges détaillés du protocole Handshake pour TLS
Ci-dessous un schéma illustrant l’ensemble des échanges préalables entre le client et le serveur pour garantir la sécurité, la confidentialité et l’intégrité des messages échangés.
1- Établissement de la connexion
Le client initie la communication avec le serveur en envoyant un message SYN (Synchronize). Le serveur accepte la communication en envoyant un message SYN-ACK (synchronize-acknowledgment). Enfin, le client informe le serveur de la bonne réception du message reçu en envoyant un ACK (acknowledgment).
2- Négociation
Le client envoie le message CLIENT_HELLO en clair au serveur contenant:
- La version de TLS (la plus récente que peut utiliser le client)
- Un message aléatoire pour la signature des données
- Un identifiant de session
- La liste des suites d’algorithmes cryptographiques supportés par le client par ordre décroissant de préférence.
Le serveur répond au client avec un message SERVER_HELLO contenant la version de TLS du client, le message aléatoire envoyé par le client, l’identifiant de session et la plus forte suite d’algorithme commune entre le client et le serveur.
Si la version TLS ou la suite d’algorithmes proposés par le client ne sont pas disponibles côté serveur, la communication s’interrompt.
3- Authentification du serveur
Une fois les algorithmes négociés, le serveur s’authentifie auprès du client en envoyant son certificat X.509 (message Certificate).
En option, le serveur envoie également sa clé publique (différente de la clé publique du certificat serveur) au client pour chiffrer la clé de session (Server Key Exchange). En fonction de la configuration du serveur, il envoie le message Client Certificate Request afin de demander au client son propre certificat.
Le client vérifie le format du certificat, sa date d’expiration, son statut révoqué ou non et si le certificat est de confiance. La chaine d’Autorité du certificat serveur doit pour cela être embarquée dans le magasin de confiance du client. Si au moins une de ces vérifications échoue, la transaction est abandonnée.
Enfin, le serveur envoie le message Server Hello Done pour indiquer qu’il a terminé.
4- Authentification du client et génération de la clé de session
Le client envoie son propre certificat au serveur (Client Certificate), si demandé. Le serveur procède aux mêmes vérifications que celles faites par le client (voir point 3) sur le certificat serveur.
Le client produit un secret pré-maître (pre-master key) qu’il chiffre avec la clé publique du certificat serveur. Si le serveur a envoyé Server Key Exchange, cette clé chiffrée est chiffrée à nouveau avec la clé publique du serveur. Le message Client Key Exchange envoie le résultat au serveur. Ce secret permet par la suite au client et au serveur de générer des clés de sessions non échangées.
Si le client a envoyé son certificat, il envoie aussi le message Certificate Verify, contenant l’empreinte de tous les messages précédents signée avec la clé privée du client. Ce message permet de prouver que le client possède bien la clé privée associée à son certificat.
5- Fin du Handshake TLS
Le client envoie deux messages Change Cipher Spec et Finished chiffrés et signés avec les clés vues précédemment pour indiquer que le tunnel TLS s’est établi. Le serveur fait de même, c’est la fin du Handshake.
A partir de ce moment, le client et le serveur communiquent en suivant les spécifications du protocoles Record, en garantissant la confidentialité et l’intégrité de tous les messages échangés.
