Que se passe-t-il lors d'une négociation TLS ? | Négociation SSL

Qu'est-ce qu'une négociation TLS ?

Le TLS est un protocole de chiffrement conçu pour sécuriser les communications Internet. La négociation TLS (également nommée handshake) désigne le processus qui amorce une session de communication utilisant le chiffrement TLS. Au cours de cette négociation, les deux parties communicantes s'échangent l'une l'autre des messages d'authentification et de vérification, établissent les algorithmes de chiffrement qu'elles utiliseront et se mettent d'accord sur les clés de session. Cette négociation constitue un élément fondamental du fonctionnement du protocole HTTPS.

Négociations TLS et SSL

Le SSL, ou Secure Sockets Layer, était le protocole de chiffrement initialement développé pour HTTP. Il a été remplacé depuis un certain temps par le TLS, ou Transport Layer Security. Les négociations SSL sont désormais appelées négociations TLS, bien que le nom SSL reste toujours largement utilisé.

À quel moment une négociation TLS intervient-elle ?

Une négociation TLS a lieu chaque fois qu'un utilisateur accède à un site web via HTTPS et que le navigateur commence à interroger le serveur d'origine du site web. Cette négociation intervient également chaque fois que d'autres communications utilisent le protocole HTTPS, y compris les appels d'API et les requêtes DNS sur HTTPS.

Les négociations TLS se produisent après l'ouverture d'une connexion TCP par l'intermédiaire d'une négociation TCP.

Que se passe-t-il lors d'une négociation TLS ?

Au cours d'une négociation TLS, le client et le serveur effectuent ensemble les opérations suivantes :

• Préciser quelle version de TLS (TLS 1.0, 1.2, 1.3, etc.) ils utiliseront.
• Décider quelles suites de chiffrement (voir ci-dessous) ils utiliseront.
• Authentifier l'identité du serveur à l'aide de la clé publique du serveur et de la signature numérique de l'autorité de certification SSL.
• Générer des clés de session afin d'utiliser le chiffrement symétrique une fois la négociation terminée.

Quelles sont les étapes d'une négociation TLS ?

La négociation TLS se compose d'une série de datagrammes (ou messages) échangés par un client et un serveur. Elle implique plusieurs étapes, car le client et le serveur échangent les informations nécessaires pour terminer la négociation et rendre la conversation possible.

Les étapes exactes d'une poignée de main TLS varient en fonction du type d'algorithme d'échange de clés utilisé et des suites de chiffrement prises en charge par les deux parties. L'algorithme d'échange de clés RSA, bien que considéré aujourd'hui comme non sécurisé, était utilisé dans les versions de TLS antérieures à la version 1.3. Cela se passe à peu près comme suit :

1. Message « Client Hello » : le client démarre la négociation en envoyant un message « Hello » au serveur. Le message inclut la version TLS prise en charge par le client, les suites de chiffrement prises en charge et une chaîne d'octets aléatoires connue sous le nom de « client random », ou nombre aléatoire client.
2. Message « Server Hello » : en réponse au message Client Hello, le serveur envoie un message contenant le certificat SSL du serveur, la suite de chiffrement choisie par le serveur et le « Server random », une autre chaîne aléatoire d'octets générée par le serveur.
3. Authentification : le client vérifie le certificat SSL du serveur auprès de l'autorité de certification qui l'a émis. Cette opération confirme que le serveur est bien celui qu'il prétend être et que le client interagit avec le véritable propriétaire du domaine.
4. Secret pré-maître : le client envoie une autre chaîne d'octets aléatoire, le « premaster secret », ou secret pré-maître. Le secret pré-maître est chiffré à l'aide de la clé publique et ne peut être déchiffré par le serveur qu'avec la clé privée. (Le client obtient la clé publique dans le certificat SSL du serveur.)
5. Utilisation de la clé privée : le serveur déchiffre le secret pré-maître.
6. Création des clés de session : le client et le serveur génèrent des clés de session à partir du client random, du server random et du secret pré-maître. Ils doivent aboutir aux mêmes résultats.
7. Client prêt : le client envoie un message « Client Finished » chiffré à l'aide d'une clé de session.
8. Serveur prêt : le serveur envoie un message « Server Finished » chiffré à l'aide d'une clé de session.
9. Chiffrement symétrique sécurisé effectué : la négociation est terminée et la communication se poursuit à l'aide des clés de session.

Toutes les négociations TLS s'appuient sur la cryptographie asymétrique (la clé publique et la clé privée), mais toutes n'utilisent pas la clé privée dans le processus de génération des clés de session. Une négociation à clés éphémères Diffie-Hellman, par exemple, se déroule comme suit :

1. Client Hello : le client envoie un message Client Hello avec la version du protocole, le client random et une liste de suites de chiffrement.
2. Server Hello : le serveur répond avec son certificat SSL, sa suite de chiffrement sélectionnée et le server random. Contrairement à la négociation RSA décrite ci-dessus, le serveur inclut également les éléments suivants dans ce message (étape 3) :
3. Signature numérique du serveur : le serveur calcule une signature numérique de tous les messages jusqu'à ce point.
4. Signature numérique confirmée : le client vérifie la signature numérique du serveur, confirmant que le serveur est bien celui qu'il prétend être.
5. Paramètre DH client : le client envoie son paramètre DH au serveur.
6. Calcul du secret pré-maître par le client et le serveur : plutôt que le client génère le secret pré-maître et l'envoie au serveur, comme dans une négociation RSA, le client et le serveur utilisent les paramètres DH qu'ils ont échangés pour calculer séparément un secret pré-maître correspondant.
7. Création des clés de session : le client et le serveur calculent à présent les clés de session à partir du secret pré-maître, du client random et du server random, comme dans la négociation RSA.
8. Client prêt : comme dans la négociation RSA.
9. Serveur prêt
10. Chiffrement symétrique sécurisé effectué

*Paramètre DH : les lettres DH signifient Diffie-Hellman. L'algorithme Diffie-Hellman s'appuie sur des calculs exponentiels pour arriver au même secret pré-maître. Le serveur et le client fournissent chacun un paramètre pour le calcul. Une fois combinés, ces deux paramètres entraînent une procédure de calcul différente de chaque côté, pour un résultat toutefois égal.

Pour en savoir plus sur la différence entre la négociation à clés éphémères Diffie-Hellman et les autres types de négociation, ainsi que sur la manière dont ces procédures assurent la confidentialité, consultez la page Qu'est-ce que le SSL sans clé ?

Qu'est-ce qui est différent d'une poignée de main dans TLS 1.3 ?

TLS 1.3 ne prend pas en charge RSA, ni d'autres suites de chiffrement et paramètres qui sont vulnérables aux attaques. Il raccourcit également la poignée de main TLS, ce qui rend la poignée de main TLS 1.3 à la fois plus rapide et plus sûre.

Les étapes de base d'une poignée de main TLS 1.3 sont les suivantes :

• Message d'accueil du client : le client envoie un message d'accueil du client contenant la version du protocole, le hasard du client et une liste de suites de chiffrement.La prise en charge des suites de chiffrement non sécurisées ayant été supprimée de TLS 1.3, le nombre de suites de chiffrement possibles est considérablement réduit.Le bonjour du client comprend également les paramètres qui seront utilisés pour calculer le secret du prémaître.Essentiellement, le client suppose qu'il connaît la méthode d'échange de clés préférée du serveur (ce qui est probablement le cas, étant donné la liste simplifiée des suites de chiffrement).Cela réduit la longueur totale de la poignée de main - l'une des différences importantes entre les poignées de main TLS 1.3 et les poignées de main TLS 1.0, 1.1 et 1.2.
• Le serveur génère le secret principal : à ce stade, le serveur a reçu les paramètres et les suites de chiffrement aléatoires du client.Il possède déjà le serveur aléatoire, puisqu'il peut le générer lui-même. Par conséquent, le serveur peut créer le secret principal.
• Serveur hello et « Fini »: le serveur hello comprend le certificat du serveur, la signature numérique, le serveur aléatoire et la suite de chiffrement choisie.Comme il possède déjà le secret maître, il envoie également un message « Fini ».
• Étapes finales et client « Fini »: le client vérifie la signature et le certificat, génère le secret maître et envoie le message « Fini ».
• Chiffrement symétrique sécurisé effectué

Mode 0-RTT pour la reprise de session

TLS 1.3 prend également en charge une version encore plus rapide de la négociation TLS qui ne nécessite aucune communication aller-retour entre le client et le serveur. Si le client et le serveur se sont déjà connectés l'un à l'autre (par exemple, si l'utilisateur a déjà consulté le site web), ils peuvent chacun déduire un autre secret partagé de la première session, appelé « secret principal de reprise ». Au cours de cette première session, le serveur envoie également au client ce qu'on appelle un ticket de session. Le client peut utiliser ce secret partagé pour envoyer des données chiffrées au serveur dans son premier message de la session suivante, avec ce ticket de session. Et TLS reprend entre le client et le serveur.

Qu'est-ce qu'une suite de chiffrement ?

Une suite de chiffrement est un ensemble d'algorithmes utilisés pour établir une connexion de communication sécurisée. Il existe un certain nombre de suites de chiffrement largement utilisées, et une partie essentielle de la poignée de main TLS consiste à convenir de la suite de chiffrement qui sera utilisée pour cette poignée de main.

Pour en savoir plus sur le protocole TLS/SSL, consultez la page Comment fonctionne le SSL ?