Si vous avez déjà navigué sur une URL HTTPS via un navigateur, vous avez fait l’expérience du handshake SSL. Même si vous ne le remarquez peut-être pas, le navigateur et le site Web créent une connexion HTTPS en utilisant une poignée de main SSL à sens unique.
Le principal objectif d’une poignée de main SSL est de fournir la confidentialité et l’intégrité des données pour la communication entre un serveur et un client. Au cours du Handshake, le serveur et le client vont échanger des informations importantes nécessaires à l’établissement d’une connexion sécurisée.
Il existe deux types de handshake SSL décrits comme SSL unidirectionnel et SSL bidirectionnel (Mutual SSL). La différence entre ces deux est que dans le SSL unidirectionnel, seul le client valide l’identité du serveur alors que dans le SSL bidirectionnel, le serveur et le client valident l’identité de l’autre. En général, lorsque nous naviguons sur un site Web HTTPS, le protocole SSL unidirectionnel est utilisé et seul notre navigateur (client) valide l’identité du site Web (serveur). Le SSL bidirectionnel est surtout utilisé dans les communications de serveur à serveur où les deux parties doivent valider l’identité de l’autre.
Pendant une poignée de main SSL, le serveur et le client suivent l’ensemble des étapes ci-dessous.
1. Allô client
Le client envoie les informations qui seront requises par le serveur pour démarrer une connexion HTTPS.
Dans le journal ci-dessus, nous pouvons voir que le client allume avec TLS v1.2. Par ceci, le client notifie au serveur qu’il a le support pour les versions 1.2 et inférieures de TLS. La liste des chiffrements qui sont supportés par le client peut également être vue dans le journal ci-dessus. Dans cette liste, le serveur sélectionnera une suite de chiffrement qu’il supporte. Si la liste contient des suites de chiffres que le serveur ne reconnaît pas, ne prend pas en charge ou ne souhaite pas utiliser, le serveur ignorera ces chiffres. Si aucune suite de chiffrement prise en charge n’a été trouvée, le serveur enverra une alerte d’échec et fermera la connexion.
2. Server Hello
Le serveur répondra en retour avec la configuration qu’il a sélectionnée dans le Client Hello ainsi que ses informations pour procéder à la poignée de main. Le Server Hello sera le suivant.
Sever sélectionnera la version TLS selon la plus faible de celle suggérée par le client dans le message Client Hello et la plus élevée supportée par le serveur. Le serveur renverra également la suite de chiffrement qu’il a sélectionnée dans la liste de chiffrement présentée par le client.
Avec le message Server Hello, le serveur enverra également le certificat du serveur avec la chaîne de certificats. La chaîne de certificats sera validée par rapport aux certificats dans le magasin de confiance du client.
3. Message d’échange de clés du serveur
Ce message sera envoyé par le serveur au client portant les détails requis pour que le client génère le secret pré-maître. Ce message ne sera pas envoyé si l’algorithme d’échange de clés RSA (plus à ce sujet plus tard) ou tout autre algorithme d’échange de clés est utilisé qui ne nécessite pas les informations du serveur pour générer un secret pré-maître.
Pour l’échange de clés Elliptic Curve Diffie Hellman(ECDH), les détails suivants sur la clé publique ECDH du serveur sont envoyés au client.
4. Demande de certificat
C’est l’endroit où le SSL unidirectionnel diffère du SSL bidirectionnel. Dans le SSL unidirectionnel, l’authenticité du client n’est pas validée. Par conséquent, cette étape est omise dans la poignée de main SSL à sens unique.
Pendant cette étape, le serveur enverra une demande de certificat du client avec le type de certificat, les algorithmes de signature de certificat et les autorités de certification supportés par le serveur. Il peut y avoir des situations où la liste des autorités de certification peut être vide. Dans de tels scénarios, le client peut choisir d’envoyer ou d’éviter l’envoi du certificat du client (dépend de l’implémentation du client)
Enfin, le serveur envoie le message Server Hello Done indiquant la fin de Server Hello. Après avoir envoyé ce message, le serveur attend une réponse du client.
5. Certificat du client
Le client présente sa chaîne de certificats au serveur. Le certificat doit être approprié pour l’algorithme d’échange de clés de la suite de chiffrement négociée, et toute extension négociée.
6. Message d’échange de clés du client
Ce message doit être envoyé par le client après le message de certificat du client. Si le certificat du client n’est pas présenté (en SSL unidirectionnel), le message d’échange de clé du client doit être envoyé après que le client ait reçu le message ServerHelloDone.
Comme nous le savons tous, les données transférées entre le serveur et le client dans une connexion HTTPS seront cryptées. Le cryptage symétrique est utilisé à cette fin car le coût de calcul est beaucoup plus faible que le cryptage asymétrique. Pour utiliser le cryptage symétrique, il faut qu’il y ait une clé commune entre les deux extrémités. Le but de ce message est de générer cette clé commune entre ce client et le serveur sans l’exposer à une personne extérieure.
Il existe deux méthodes d’échange de clé client décrites dans la spécification TLS v1.2. Ce sont RSA et Diffie-Hellman.
Si RSA est utilisé comme algorithme d’échange de clés, le client génère un secret pré-maître de 48 octets. Le client chiffre le secret pré-maître par la clé publique du certificat et l’envoie au serveur. Seul le serveur aura la clé privée correspondante pour déchiffrer et obtenir le secret pré-maître généré par le client.
Si Diffie-Hellman est utilisé, les paramètres de Diffie-Hellman sont transmis pour permettre au client et au serveur de générer le même secret pré-maître.
Après cela, les deux parties généreront un secret maître en utilisant le secret pré-maître et le secret maître sera utilisé pour générer la clé symétrique pour chiffrer les données de session
7. Finished
Après une authentification réussie et la génération des secrets pré-maître/secrets maîtres, un message change cipher spec sera envoyé par le client et le serveur indiquant que le reste de la communication sera chiffré.
Le message Finished suivra immédiatement le message change cipher spec. Ce sera le premier message crypté avec les algorithmes négociés. Les données d’application ne seront transférées qu’après l’envoi du message finished par les deux parties et la vérification du contenu du message.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/