Qu’est-ce qu’une poignée de main SSL/TLS ?

Une poignée de main SSL/TLS est une négociation entre deux parties sur un réseau – comme un navigateur et un serveur web – pour établir les détails de leur connexion. Elle détermine quelle version de SSL/TLS sera utilisée dans la session, quelle suite de chiffrement chiffrera la communication, vérifie le serveur (et parfois aussi le client) et établit qu’une connexion sécurisée est en place avant de transférer des données.

Tout cela se passe en arrière-plan, heureusement – chaque fois que vous dirigez votre navigateur vers un site sécurisé, une interaction complexe a lieu pour s’assurer que vos données sont en sécurité.

C’est la version simple. Vous pouvez remarquer que n’importe quelle douzaine de descriptions s’en tiendra plus ou moins à ce format, tout en différant dans les détails d’une douzaine de façons différentes – parfois de manière confuse. Jetons un tableau qui montre un modèle général de la façon dont une poignée de main TLS fonctionne, d’accord ?

Vous avez besoin d’un certificat ? SSL.com s’occupe de vous. Comparez les options ici pour trouver le bon choix pour vous, des certificats S/MIME et de signature de code et plus.

COMMANDEZ MAINTENANT

Graphique obligatoire de la poignée de main SSL/TLS

Tous les sites liés à SSL/TLS ont leur propre version d’un diagramme de poignée de main – voici le nôtre ! (Cliquez pour agrandir.)

Eclaircissons certaines confusions, si nous le pouvons

Certaines confusions sur le fonctionnement des handshakes SSL/TLS sont dues au fait que le handshake n’est que le prélude à la session réelle et sécurisée elle-même. Essayons d’aborder certains points communs :

Cryptage asymétrique vs symétrique

La poignée de main elle-même utilise un cryptage asymétrique – deux clés distinctes sont utilisées, une publique et une privée. Comme les systèmes de cryptage asymétrique ont des frais généraux beaucoup plus élevés, ils ne sont pas utilisables pour fournir une sécurité à plein temps, dans le monde réel. Ainsi, la clé publique est utilisée pour le cryptage et la clé privée pour le décryptage pendant la poignée de main uniquement, ce qui permet aux deux parties d’établir et d’échanger confidentiellement une « clé partagée » nouvellement créée. La session elle-même utilise cette clé partagée unique pour effectuer un cryptage symétrique, et c’est ce qui rend une connexion sécurisée réalisable dans la pratique (l’overhead est beaucoup plus faible). Ainsi, la réponse complète et correcte à la question « Le chiffrement SSL/TLS est-il asymétrique ou symétrique ? » est « D’abord l’un, puis l’autre. »

Qu’est-ce qu’une « suite de chiffrement » ?

La poignée de main elle-même comporte plusieurs étapes, chacune gérée selon des règles différentes. Les détails peuvent être trouvés ici, mais l’essentiel est que, plutôt que de mener une série de négociations séparées dans les deux sens (sur les clés à utiliser, la façon de chiffrer la poignée de main elle-même, la façon d’authentifier la poignée de main et ainsi de suite), les parties peuvent convenir d’utiliser une « suite de chiffrement » – une sélection ou un kit préexistant de composants convenus. (N’oubliez pas que le cryptage asymétrique est coûteux en temps et en ressources – l’utilisation de la suite de chiffres comme raccourci accélère la poignée de main elle-même). Les spécifications TLS permettent un assez grand nombre de suites de chiffrement, et le client et le serveur auront presque toujours accès à une qu’ils peuvent tous deux employer.

Prise de contact de base vs mutuellement authentifiée

Un autre point déroutant est que le modèle de base que nous avons décrit ci-dessus laisse le client vérifier le serveur, et la grande majorité des sessions sécurisées par TLS ne nécessitent que cela. Cependant, certaines suites de chiffrement exigeront que le client envoie également un certificat et une clé publique pour l’authentification mutuelle des deux parties. Cette authentification bidirectionnelle ajoutera bien sûr des frais généraux à la poignée de main – cependant, dans certains cas (par exemple, lorsque deux banques négocient une connexion sécurisée pour les transferts de fonds), la suite de chiffrement insistera sur ce point, et la sécurité supplémentaire est jugée en valoir la peine.

Des sessions différentes auront des paramètres de sécurité différents

Chaque nouvelle poignée de main crée une nouvelle session, et les paramètres utilisés dans l’une peuvent différer radicalement d’une autre selon la suite de chiffrement choisie. C’est l’une des raisons pour lesquelles il existe tant d’itérations différentes de ce satané tableau de poignée de main, et pourquoi nous donnons ici un aperçu assez large. Sachez également que les sessions peuvent définir des paramètres qui ne correspondent pas exactement à ce que vous attendez. Selon la suite de chiffrement, certaines étapes peuvent être ajoutées (comme l’exigence d’une authentification bidirectionnelle) ou absentes. En fait, il existe des suites de chiffrement qui négocient une session sans utiliser le moindre chiffrement. (Oui, nous savons, une connexion HTTPS sur le port 443 qui décide d’envoyer des données en clair n’a aucun sens pour nous non plus. SSL.com vous recommande vivement de ne pas faire cela – sachez simplement que c’est dans le domaine du possible).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.