Server—ServerKeyExchange

Ce message porte les paramètres de l’algorithme d’échange de clés dont le client a besoin du serveur afin de dériver des secrets intermédiaires qui seront utilisés lors de la construction des clés de session finales pour le chiffrement symétrique par les deux parties. Il est facultatif, car certains algorithmes d’échange de clés tels que RSA key exchange ne nécessitent pas ces paramètres, car le certificat du serveur lui-même sera suffisant pour que le client construise et communique en toute sécurité le secret pré-maître avec le serveur.

Par ex. si la méthode d’échange de clés choisie par le serveur dans une étape précédente est Diffie–Hellman (DH), le serveur inclut ce message après le certificat, qui inclura les composants publics nécessaires à la génération du secret maître.

Server-CertificateRequest

Ce message sera envoyé si l’authentification du client SSL est activée sur le serveur. Ceci n’est normalement pas requis dans la plupart des serveurs Web, mais pour des exigences de sécurité élevées, le serveur peut exiger le certificat du client pour l’authentification. Avec la demande de certificat, le serveur envoie les types de clients acceptables et indique également une liste de noms distinctifs d’autorités de certification approuvées par le serveur. Cette liste comprend les autorités de certification disponibles dans le truststore du serveur.

Server-ServerHelloDone

Enfin, le serveur envoie le message ServerHelloDone indiquant au client que le serveur a fini de transmettre les paramètres de sécurité. Ce message termine la partie du serveur de la négociation de la poignée de main. Ce message ne portera aucune autre information.

Certificat client

Le client répond avec un certificat client si le serveur demande une authentification client avec un message de demande de certificat. Cependant, avant l’envoi du certificat, le client vérifiera le DN de l’émetteur du certificat du client se trouve dans la liste des noms distinctifs des autorités de certification de confiance envoyées par le serveur. Si le DN de l’émetteur n’a pas été trouvé, le client n’enverra pas son certificat au serveur. Côté serveur, si l’authentification par certificat client est obligatoire, la prise de contact TLS échouera ici. Sinon, le client enverra son certificat et tous les certificats intermédiaires nécessaires qui enchaînent au DN correspondant répertorié dans le message de demande de certificat.

Client-ClientKeyExchange

Le message ClientKeyExchange contient le secret pré-maître, qui est généré par le client. Ceci est effectué selon la suite de chiffrement agrégé par les deux parties dans une étape précédente. Le client et le serveur l’utiliseront tous deux pour générer un secret maître à partir duquel ils dériveront tous les deux les clés cryptographiques finales requises pour établir le canal encypté. Le client crypte le secret pré-maître avec la clé publique du serveur de sorte que si un écouteur interceptait ce bit de données, il ne pourra pas le déchiffrer puisqu’il n’a pas accès à la clé privée du serveur. La clé principale fournit au serveur les données nécessaires pour générer les clés pour le chiffrement symétrique. Cependant, si la suite de chiffrement choisie pour cette session était DH, le ClientKeyExchange contient les paramètres DH publics du client au lieu d’un secret pré-maître.

Client—CertificateVerify

Ce message est utilisé par le client pour prouver au serveur qu’il possède la clé privée correspondant à son certificat de clé publique. Le message contient des informations hachées (hachage de tous les messages échangés jusqu’à présent pendant le processus de prise de contact) qui sont signées numériquement par le client. Il est requis si le serveur a émis une demande de certificat au client, afin que le client ait envoyé un certificat en réponse qui doit être vérifié côté serveur.

Client-ChangeCipherSpec

Le message ChangeCipherSpec est juste un message du client pour informer le serveur que toutes les données que le client envoie à partir de là seront cryptées en utilisant les paramètres de sécurité convenus. À ce stade, le client et le serveur ont tous les composants nécessaires pour générer le secret maître, puis dériver des clés de session cryptographiques.
Les deux parties vérifient que la poignée de main s’est déroulée comme prévu et que les deux ont généré des clés identiques en envoyant un message final chiffré Fini indiquant l’une à l’autre que la suite chiffrée est activée.

Client fini

Tout d’abord, le client envoie un message fini chiffré au serveur. Ce message est un hachage cryptographique (résumé de message), de tous les messages de prise de contact précédents combinés, suivi d’un numéro spécial identifiant le rôle du client, le secret principal et le remplissage. Ceci est chiffré avec la clé de session nouvellement générée et envoyé au serveur.

Server-ChangeCipherSpec

Maintenant, le serveur envoie un message ChangeCipherSpec au client pour lui dire que toutes les données après ce message seront cryptées.

Fin du serveur

Le message ChangeCipherSpec est suivi d’un message fini chiffré du serveur au client. Il s’agit d’un hachage cryptographique généré par le serveur, de tous les composants utilisés pendant le processus hanshake avec un numéro spécial identifiant le rôle du serveur.