Blog

Poignées de main TLS (SSL) expliquées

Les poignées de main TLS (SSL) ne semblent peut-être pas très familières, mais elles constituent l'un des éléments les plus critiques d'une connexion sécurisée à un site Web. TLS signifie Transport Layer Security, tandis que SSL est l'abréviation de Secure Sockets Layer. Les gens utilisent souvent les termes de manière interchangeable, mais TLS n’est en réalité que la version mise à jour de SSL.

La prise de contact TLS est un élément essentiel du protocole TLS global. Il s’agit d’un sous-protocole chargé d’établir en toute sécurité les paramètres de la connexion. Une fois la connexion TLS établie, les données sont envoyées de manière sécurisée via la couche d'enregistrement, qui est l'autre sous-protocole principal de TLS.

La poignée de main TLS joue un rôle important dans une grande partie de votre sécurité en ligne. Il s’agit d’un élément clé de la mise en place de connexions sécurisées, depuis les appels VOIP jusqu’à votre page de connexion par courrier électronique.

Qu'est-ce que TLS (SSL) ?

Sécurité de la couche de transport (TLS) est un protocole qui peut assurer la sécurité sur des réseaux comme Internet. Si nous n’avions pas de protocoles de sécurité, nous serions confrontés à toute une série de problèmes, notamment lors du transport de données sensibles et importantes.

Sans protocoles de sécurité :

Il n’y aurait aucun moyen de protéger les détails intimes que vous avez partagés dans vos messages privés.
Vous ne saurez pas si vous vous trouvez réellement sur le site Internet de votre banque ou sur une copie frauduleuse.
Vous ne pouviez pas empêcher vos messages d’être modifiés par des attaquants avant qu’ils ne soient remis à vos destinataires.

TLS est l'un des mécanismes développés pour résoudre ces problèmes, et il est capable de :

Authentifiez les autres parties.
Indiquez si les données conservent leur intégrité.
Gardez les données confidentielles.

TLS fonctionne entre les couches réseau et application du Modèle OSI . La prise de contact TLS (SSL) est une couche du protocole TLS et son objectif est d'authentifier l'autre partie et d'établir des paramètres sécurisés pour l'échange de données. L'autre couche majeure est l'enregistrement TLS, qui utilise les paramètres définis lors de la poignée de main pour envoyer en toute sécurité les données entre les parties. Il transmet ces données dans des paquets appelés enregistrements.

Un bref aperçu de TLS (SSL)

TLS a commencé sa vie grâce à un initiative commune de plusieurs agences et entreprises du gouvernement américain dans les années 80. Il a évolué vers différentes versions de Secure Sockets Layer (SSL) dans les années 1990. En 1999, la version mise à jour du protocole a vu son nom changé pour Transport Security Layer, dans le cadre de ce qui était essentiellement un compromis entre Microsoft et Netscape. La dernière version est TLS 1.3, que les dernières versions de navigateurs comme Chrome et Firefox utilisent par défaut.

Les usages de TLS (SSL)

De nos jours, vos données transitent souvent via TLS chaque fois que vous êtes en ligne. TLS fournit la sécurité HTTPS, qui est utilisée par la plupart des principaux sites Web pour protéger vos données. C’est particulièrement courant sur les pages de connexion et dans les services bancaires en ligne. Vous pouvez savoir quand un site Web est sécurisé par TLS, car l'URL commencera par https plutôt que http , et il y aura une petite icône de cadenas à gauche de la barre d'adresse.

TLS peut également être implémenté sur un certain nombre d'autres protocoles de couche transport pour assurer la sécurité. Ceux-ci incluent SMTP, FTP, XMPP et autres. Lorsque TLS est en place parallèlement à ces protocoles, il peut protéger respectivement les e-mails, les transferts de fichiers et la messagerie instantanée. TLS peut également être utilisé pour protéger les données transmises via les VPN.

Qu'est-ce qu'une poignée de main ?

Lorsque vous allez en ligne, vous ne réfléchissez probablement pas beaucoup à ce qui se passe sous le capot pour que tout se réalise. Vous vous souciez probablement beaucoup plus des mèmes ou des vidéos YouTube que des détails techniques complexes de la façon dont ils arrivent sur votre téléphone.

Même si cela peut être instantané, beaucoup de choses doivent se produire pour que votre appareil (le client) se connecte à un site Web comme Facebook, qui fait office de serveur. Notre écosystème d’informations est composé d’un énorme méli-mélo de normes, protocoles, procédures, chiffres et bien plus encore.

Le client (votre téléphone ou votre ordinateur) en prendra en charge plusieurs dans un ordre de préférence, alors qu'il ne sera pas compatible avec d'autres. Le serveur de Facebook fera de même, mais bon nombre de ses protocoles, normes, chiffrements et tout le reste peuvent être différents de ceux de votre téléphone ou de votre ordinateur. Certains clients et serveurs ne disposeront pas des dernières versions, tandis que d’autres refuseront de se connecter de manière non sécurisée.

Essentiellement, lorsque le client et le serveur se rencontrent, ils doivent trier ce désordre de systèmes différents pour trouver un moyen de communication acceptable et mutuellement intelligible. C'est à cela que sert la poignée de main. Il peut être utile de penser à la poignée de main à travers une analogie :

Voyageurs venus de pays lointains

Imaginez deux personnes venues de pays lointains communiquant pour la première fois. Ils viennent de cultures extrêmement différentes, avec leurs propres langues, coutumes, manières et bien plus encore. Cependant, les deux personnes ont extrêmement voyagé et ont découvert de nombreux systèmes différents des endroits qu'ils ont traversés.

Les deux personnes souhaitent faire des affaires ensemble et doivent donc pouvoir communiquer de manière claire et efficace. Mais comment y parvenir alors qu’ils ont le choix entre tant d’options différentes ? S’ils ne se mettent pas d’accord au préalable, ils risquent de confondre le « nein » allemand avec le chiffre « neuf ». Un coup de pouce amical occidental pourrait être interprété à tort comme un geste offensant de l’Iran.

Et s’ils voulaient garder leurs communications confidentielles ? Devraient-ils utiliser un simple chiffre de César, où chaque lettre est décalée d’une place vers la droite. A est égal à B, B est égal à C, C est égal à D, et ainsi de suite. Cela transformerait un mot comme « Bonjour » en « Ifmmp ». Ou devraient-ils utiliser un système comme Pig Latin, où « Bonjour » serait en réalité « ello-hay » ?

Comme vous pouvez le constater, ils ont le choix entre de nombreuses options, mais l’important est qu’ils soient tous deux d’accord sur les systèmes qu’ils utiliseront et sur la manière dont ils les utiliseront. Une bonne façon de prendre une décision consiste simplement à énumérer toutes les options qu’ils connaissent, par ordre de préférence.

Le voyageur A pourrait dresser une liste comme celle-ci :

Alphabet
- romain
- arabe
- cyrillique
Langue
- Anglais
- Espagnol
- arabe
- russe
Gestes
- Occidental
- Sud-asiatique
Chiffres
- Cochon latin
- Chiffre de César
Unité de mesure
- Métrique
- Impérial

Le voyageur B pourrait alors parcourir la liste et choisir ses préférences parmi les options disponibles. Ils peuvent renvoyer un message avec leurs choix, par exemple :

Alphabet – Romain
Langue – espagnol
Gestes – Asie du Sud
Chiffre – Cochon Latin
Unité de mesure – Métrique

Une fois que le voyageur A recevra le message du voyageur B, il saura exactement comment communiquer dans sa future correspondance. Ils pouvaient clairement discuter ou envoyer des lettres concernant leurs relations commerciales, sans se perdre. Les communications ne seraient pas cryptées avec un chiffre que l’autre partie ne pourrait pas déchiffrer, et ils ne se retrouveraient pas non plus avec 1 000 livres de blé alors qu’ils en voulaient vraiment 1 000 kg.

Handshaking : établissement des paramètres de communication

La scène que nous avons décrite ci-dessus est analogue à ce qui se passe lors d’une poignée de main plus technique. La seule différence majeure réside dans les types de paramètres utilisés dans les communications informatiques. Ceux-ci varient d’un protocole à l’autre, mais ils peuvent inclure des éléments tels que :

Alphabet de codage
Procédures d'interruption
Chiffres
Clés
Compression
Parité
Taille du message

Certaines procédures de prise de contact peuvent être relativement simples, tandis que d'autres peuvent comprendre de nombreuses étapes et paramètres distincts qui doivent être décidés. L’important est qu’à la fin, les deux parties se retrouvent avec un moyen de communication convenu d’un commun accord, qu’elles pourront ensuite utiliser dans leurs interactions futures.

Versions TLS

En janvier 2021, 42,1 % des 150 000 sites Web les plus populaires du classement Alexa prenaient en charge TLS 1.3, selon Impulsion SSL . La même source indique que 99,2 % de ces sites Web prennent en charge la version précédente de TLS 1.2, tandis que 55,9 % prennent en charge TLS 1.1 et 49,4 % prennent en charge TLS 1.0. Seule une très petite fraction prend en charge l’une ou l’autre version de SSL.

Les dernières versions de la plupart des principaux navigateurs ont soit déjà désactivé leur prise en charge par défaut des versions 1.0 et 1.1 de TLS, soit elles le feront en 2021. Cela inclut Google Chrome , Microsoft Bord , Safari d'Apple et Mozilla Firefox . De nombreux autres logiciels populaires emboîtent également le pas.

TLS 1.3 sera au centre de notre article, car il s’agit de la version la plus récente et la plus sécurisée, et le monde s’y dirige lentement. Bien que les autres versions accomplissent à peu près la même tâche, il existe plusieurs différences clés qui les rendent moins efficaces et plus vulnérables aux attaques que TLS 1.3.

La poignée de main TLS (SSL) : la version courte

Le client se connecte au serveur et envoie un message Client Hello. Ce message inclut les paramètres qu'il prend en charge, tels que :

Les versions de TLS avec lesquelles il est compatible.
Une occasion.
Les suites de chiffrement qu'il peut utiliser pour le cryptage et l'authentification.
Un certain nombre d'extensions qui ajoutent des fonctionnalités. Cela inclut des éléments tels que les paramètres de partage des clés et un certain nombre d'extras.

En prévision du fait que le serveur acceptera bon nombre des mêmes paramètres que ceux préférés du client, le Client Hello inclut également des informations qui aident le serveur à établir une connexion sécurisée dans le cadre de sa réponse. Lorsque tel est le cas, il enregistre une série de messages. Cela rend TLS 1.3 plus rapide que les versions précédentes du protocole. Si le serveur ne peut pas répondre aux attentes du client, celui-ci devra renégocier.

Lorsque le serveur reçoit le message Client Hello, il envoie au client un message Server Hello en réponse. Cela inclut ses choix dans la liste de préférences du Client :

La version de TLS.
Une occasion.
La suite de chiffrement.
Ce sont des paramètres de partage clés.

Chacun des aspects ci-dessus est envoyé sous forme de texte brut, mais le Server Hello comprend également des messages supplémentaires qui ont été chiffrés avec des clés dérivées des aspects informatifs du message Server Hello. Ceux-ci inclus:

Le certificat du serveur.
Un message de vérification de certificat contenant une signature numérique du serveur.
Un message Terminé, qui contient un HMAC que le client peut utiliser pour vérifier l'authenticité du message.

Une fois que le serveur envoie le message Terminé, il peut commencer à envoyer les données d'application au client. Ces données d'application sont cryptées avec un ensemble différent de matériel de chiffrement.

À moins que le client ne s'authentifie également auprès du serveur (auquel cas il doit envoyer son certificat et le message Certificate Verify), il lui suffit d'envoyer son message Terminé, qui est également crypté. Il peut alors commencer à envoyer des données d'application au serveur, bien que celles-ci soient cryptées avec un matériel de chiffrement différent. À ce stade, la négociation TLS est terminée.

La poignée de main TLS (SSL) en profondeur

Jetons un coup d'œil à ce à quoi ressemble une poignée de main TLS (SSL) typique. Lorsque vous visitez comparitech.com, votre navigateur agit en tant que client, qui se connecte au serveur, amenant finalement notre page Web sur votre écran. Sous TLS, lorsque le client souhaite se connecter au serveur, la première étape consiste pour le client à envoyer au serveur un message Client Hello.

Le Client Bonjour

Un message Client Hello ressemble à ceci dans WireShark :

Comme vous pouvez le constater, cela semble un peu compliqué. Nous nous contenterons de discuter des parties les plus importantes.

Version TLS

Dans la deuxième ligne, il est écrit Couche d'enregistrement TLSv1.3 : Protocole de prise de contact : Bonjour client . Cependant, si nous sautons quelques lignes, nous voyons Version : TLS 1.0 (0x0301) . Vous remarquerez peut-être également que quelques lignes plus bas, il est écrit Version : TLS 1.2 (0x0303) . Les numéros entre parenthèses derrière chaque version ne sont que des codes pour leurs versions respectives.

En regardant ces chiffres contradictoires, vous pourriez ne pas savoir quelle version de TLS le message Client Hello souhaite réellement utiliser. La réponse se trouve au plus profond du RFC , la documentation technique qui définit la norme TLS 1.3. Dans la section 4.2.1, il traite de l'extension des versions prises en charge (les extensions TLS peuvent ajouter des fonctionnalités et des capacités supplémentaires, mais elles ne sont pas obligatoires).

La RFC indique essentiellement que lorsque l'extension Supported Versions est présente, le serveur doit ignorer les autres versions mentionnées dans le message Client Hello et sélectionner à la place une version de l'extension.

Si nous ouvrons l'extension Supported Versions dans la cinquième ligne à partir du bas, nous voyons :

Ici, cela nous montre que seules les versions TLS 1.3 et 1.2 sont prises en charge. La version qui sera finalement utilisée dépendra de ce que le serveur prend en charge.

Longueur du message

En revenant vers le haut de la première image, nous voyons Longueur dans les cinquième et huitième lignes. Le premier indique 512, tandis que le second indique 508. Il s'agit simplement de la taille de leurs messages respectifs en octets, et la différence est due au fait que l'en-tête de l'enregistrement TLS lui-même occupe 4 octets.

aléatoire

Le champ en surbrillance dans la première capture indique aléatoire , et les données à côté sont un nom occasionnel de 32 octets. Il s’agit d’un nombre arbitraire qui n’est utilisé qu’une seule fois. Son objectif principal est d'arrêter rejouer les attaques . Essentiellement, l’ajout de ce numéro unique empêche un attaquant de pouvoir envoyer au client les mêmes paquets que ceux qu’il avait reçus lors d’une connexion précédente. Le nom occasionnel aléatoire est généré par un générateur de nombres aléatoires sécurisé.

ID de session Longueur et valeur

Après cela, nous avons deux champs distincts, Longueur de l'ID de session et ID de session . L'ID de session est un nombre de 32 octets et, dans les versions précédentes, il était utilisé pour reprendre les connexions lorsque le processus d'authentification avait déjà été terminé lors d'une connexion antérieure. Dans TLS1.3, l'extension de clé pré-partagée décrite ci-dessous est utilisée à la place.

Suites de chiffrement

Le Suites de chiffrement sont utilisés pour chiffrer et authentifier la connexion. En combinaison avec d’autres mécanismes cryptographiques de TLS, ces suites de chiffrement contribuent à garantir la confidentialité, l’authenticité et l’intégrité des données. Lorsque nous développons la section des suites de chiffrement, nous pouvons voir toutes les suites de chiffrement acceptées, répertoriées dans l'ordre de préférence du client :

Bien qu'il existe 18 suites différentes répertoriées, la RFC indique que TLS 1.3 ne prend en charge que cinq suites de chiffrement différentes :

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

Si vous regardez attentivement, vous verrez que les trois premiers des deux listes sont identiques, mais dans un ordre différent. Les deux derniers de la RFC ne sont pas pris en charge par le navigateur de notre exemple, c'est pourquoi ils ne sont pas inclus dans la capture Wireshark. La raison pour laquelle la capture montre 15 suites de chiffrement différentes est d'assurer une compatibilité descendante avec les anciennes versions de TLS.

Si seules les cinq suites de chiffrement TLS 1.3 étaient incluses, le navigateur ne pourrait pas se connecter de manière sécurisée aux navigateurs utilisant les versions TLS 1.2 ou antérieures. Étant donné que de nombreux serveurs n’utilisent toujours pas la dernière version, cela entraînerait d’importants problèmes de compatibilité.

Chaque suite de chiffrement est composée d'un chiffrement à clé symétrique et d'une paire de hachage HKDF. TLS 1.3 utilise uniquement cryptage authentifié avec données associées (AEAD) chiffrements comme ses chiffrements à clé symétrique. Ces algorithmes assurent à la fois l’intégrité, l’authenticité et la confidentialité des données.

HKDF sont des fonctions de dérivation de clé (KDF) basées sur des codes d'authentification de message basés sur le hachage (HMAC). TLS utilise HKDF pour extraire l'entropie et étendre les sorties générées dans le cadre du processus de dérivation de clé.

À titre d'exemple du fonctionnement des suites de chiffrement ci-dessus, TLS_AES_128_GCM_SHA256 utilise un mode de chiffrement AEAD de AES-128 GCM , avec le SHA-256 fonction de hachage comme le HKDF. Cette suite est plus puissante que la plupart des suites utilisées dans les versions précédentes de TLS.

Échange de clés

Un autre aspect essentiel pour établir une connexion sécurisée est l’échange de clés. Dans TLS 1.3, cela est réalisé grâce à des extensions. Soit l'extension Key Share, soit l'extension Pre-shared Key (cela n'a pas été utilisé dans l'exemple que nous examinons via Wireshark), ou les deux.

Le client et le serveur auront tous deux des paires de clés composées à la fois d'un clé publique et privée , qui sont mathématiquement liés. Lorsque ces paires de clés publique-privée sont utilisées parallèlement au Diffie Hellman à courbe elliptique protocole d'accord de clé, il permet au client et au serveur d'établir un secret partagé qu'ils peuvent utiliser pour chiffrer les communications futures. Grâce aux calculs complexes qui sous-tendent cet échange, les deux parties peuvent établir la clé en toute sécurité, même si un attaquant les écoute.

Dans notre capture Wireshark, à côté du premier Entrée de partage de clé : Groupe , on voit un code, x25519 , suivi de Durée d'échange de clé : 32 . Le code indique Courbe25519 , une courbe elliptique avec 128 bits de sécurité, utilisée dans le cadre du schéma d'accord de clé Diffie-Hellman à courbe elliptique. La longueur de l'échange de clé est exactement ce à quoi cela ressemble, la longueur de la clé dans l'échange.

En dessous, nous avons Échange de clés : efifecba2658 etc. C'est la clé que le client souhaite utiliser avec Curve22519, bien que la fin de celle-ci ait été coupée lors de la capture Wireshark.

En dessous, vous verrez Entrée de partage de clé : Groupe suivi du secp256r1 code. Cela fait référence aux normes pour une cryptographie efficace, tandis que le P signifie Paramètres. secp256r1 est simplement une autre courbe elliptique avec 256 bits de sécurité.

Curve25519 et secp256r1 sont les deux options fournies par le client pour l'échange de clés. Parce que x25519 vient en premier, Curve25519 est le choix préféré du client.

Lorsque l'extension Key Share est utilisée, le client envoie au serveur une ou plusieurs de ses clés publiques (mais pas leurs homologues privées) dans le cadre du message Client Hello. Dans ce cas, la clé pour Curve25519 et la clé pour la courbe secp256r1 ont été envoyées en prévision que le serveur prendra en charge au moins une de ces options. Si le serveur le fait, il peut commencer à chiffrer une partie de sa réponse lorsqu'il envoie le message Server Hello (nous en discuterons en détail plus loin dans l'article).

L’extension Key Share de TLS 1.3 constitue un écart significatif par rapport aux mécanismes utilisés dans la version 1.2 et à ceux qui l’ont précédée. Dans ces versions antérieures, un message Client Key Exchange supplémentaire était envoyé après le Client Hello. Cela signifiait qu’une plus grande partie de la poignée de main était envoyée sous forme de texte brut, la laissant visible aux attaquants.

En supposant que le serveur acceptera l'une des préférences du client et en éliminant le besoin du message Client Key Exchange, TLS 1.3 est également plus rapide et plus efficace que les versions précédentes.

Dans les cas où le serveur ne peut pas répondre aux attentes du client, le serveur envoie un Réessayez la demande Bonjour message pour tenter d'autres moyens d'établir une connexion sécurisée. Dans la plupart des cas, la présomption de TLS 1.3 finit par sauvegarder une série de messages, contribuant ainsi à accélérer l’échange. Globalement, cela s'avère plus efficace, même si les serveurs doivent parfois envoyer des messages RetryHelloRequest.

L’autre option majeure pour le partage de clés est l’extension Pre-Shared Key. Le client et le serveur ne peuvent l'utiliser que si une clé pré-partagée a déjà été établie. Cela peut être fait lors de connexions précédentes entre les deux parties ou via un mécanisme hors bande.

Lorsque le client et le serveur ont préalablement établi une clé pré-partagée, l'extension Pre-Shared Key permet au client de répertorier les options de clé pré-partagée disponibles pour le serveur. Dans notre capture Wireshark, les clés pré-partagées n'ont pas été utilisées, cette extension n'a donc eu aucun effet sur la connexion que nous observons.

Algorithmes de signature

TLS 1.3 contient deux extensions plus importantes qui déterminent lequel algorithmes de signature sera utilisé pour créer les signatures numériques qui assurent l’authentification et l’intégrité des données.

Les signatures numériques ressemblent beaucoup à votre signature manuscrite. Vous signez des reçus, des contrats et d’autres documents avec votre nom d’une manière difficile à falsifier. Cela vous donne un moyen simple et surtout fiable d’authentifier que c’est bien vous qui signez les informations. Votre signature implique que vous avez vérifié que les détails du document étaient corrects au moment de la signature, démontrant ainsi l'intégrité des données.

Les signatures numériques remplissent des rôles similaires, nous permettant de vérifier l'authenticité et l'intégrité des informations. La principale différence est qu’ils utilisent pour ce faire un mélange d’algorithmes à clé publique et de fonctions de hachage.

Le Extension des algorithmes de signature a été introduit dans TLS 1.2 et indique les types d'algorithmes de signature pris en charge par le client. Si le client souhaite que le serveur s'authentifie avec un certificat, le client doit envoyer l'extension Signature Algorithms dans le cadre de son message Client Hello.

Les algorithmes de signature répertoriés dans le message Client Hello peuvent influencer le type de certificat que le serveur enverra au client dans le cadre de son message Certificat (cela se produit plus tard, dans le cadre du Server Hello). Le serveur choisira également son algorithme de signature préféré dans la liste des clients, qui est utilisée dans le cadre du message Certificate Verify, qui est une autre partie du message Server Hello. Nous discuterons plus en détail des messages Certificate et Certificate Verify lorsque nous aborderons plus tard les détails du message Server Hello.

La deuxième extension est la Extension du certificat d'algorithmes de signature , qui a été ajouté dans TLS 1.3. Il permet aux implémentations de montrer clairement leurs capacités dans les situations où elles prennent en charge une liste d'algorithmes pour les certificats et un ensemble distinct pour TLS lui-même.

Si une implémentation utilise le même ensemble d’algorithmes pour les certificats et TLS lui-même, le certificat des algorithmes de signature peut être omis. Si l’extension Signature Algorithm Cert n’est pas présente dans un message, alors l’extension Signature Algorithm est appliquée à la fois aux signatures des certificats ainsi qu’à TLS lui-même.

Les algorithmes de signature acceptés de TLS 1.3 incluent les éléments suivants, par ordre de préférence :

rsa_pkcs1_sha256(0x0401)
rsa_pkcs1_sha384(0x0501)
rsa_pkcs1_sha512(0x0601)
ecdsa_secp256r1_sha256(0x0403)
ecdsa_secp384r1_sha384(0x0503)
ecdsa_secp521r1_sha512(0x0603)
rsa_pss_rsae_sha256(0x0804)
rsa_pss_rsae_sha384(0x0805)
rsa_pss_rsae_sha512(0x0806)
ed25519(0x0807)
ed448(0x0808)
rsa_pss_pss_sha256(0x0809)
rsa_pss_pss_sha384(0x080a)
rsa_pss_pss_sha512(0x080b)

Les algorithmes suivants sont également inclus à des fins héritées :

rsa_pkcs1_sha1(0x0201)
ecdsa_sha1(0x0203)

Pour illustrer la signification réelle de chacun de ces codes, prenons l’exemple suivant :

rsa_pkcs1_sha256(0x0401)

Il comprend les lettres rsa , parce qu'il est basé sur le Cryptosystème RSA , opérant sous les propriétés définies dans le PKCS #1 famille de normes de cryptographie à clé publique. C'est pourquoi le pkcs1 vient ensuite. Sous cet algorithme de signature particulier, le message est haché avec la fonction de hachage SHA-256, ce qui explique le sha256 . Enfin, les crochets 0x0401 est simplement un code pour cet algorithme de signature particulier.

Méthodes de compression et autres extensions

Si vous avez suivi de près, vous avez peut-être remarqué que nous avons négligé d'aborder de nombreuses lignes dans notre capture Wireshark du message Client Hello. Ceci comprend Méthodes de compression et un tas d'extensions. Les méthodes de compression correspondent simplement au type de compression pris en charge par le client. La compression peut rendre la connexion vulnérable aux attaques par canal secondaire, c'est pourquoi TLS 1.3 définit toujours les méthodes de compression sur nul , ce qui empêche l'utilisation de la compression.

Bien que les autres extensions ajoutent des fonctionnalités supplémentaires et puissent être importantes, il n’est pas nécessaire de les étudier pour comprendre une poignée de main TLS de base.