Qu’est-ce qu’une poignée de main TLS et comment ça marche ?

TLS est l'un des outils de sécurité les plus couramment utilisés sur Internet. Le protocole fonctionne activement avec de nombreux processus de communication réseau : transferts de fichiers, connexions VPN (dans certaines implémentations pour l'échange de clés), services de messagerie instantanée ou téléphonie IP.

L’un des aspects clés du protocole est la poignée de main. C'est ce dont nous parlerons dans cet article.

« SSL/TLS handshake » est le nom de l'étape d'établissement d'une connexion HTTPS. La plupart du travail associé au protocole SSL/TLS se fait à cette étape. L'année dernière, l'IETF a finalisé TLS 1.3, réorganisant complètement le processus de prise de contact.
L'article couvrira deux types de poignées de main - pour les protocoles TLS 1.2 et TLS 1.3, que nous examinerons en partant du niveau abstrait et en approfondissant progressivement les détails :

• coordination des protocoles cryptographiques ;
• authentification à l'aide d'un certificat SSL ;
• génération de clé de session.

Comment fonctionne une poignée de main TLS ?

Une connexion HTTPS implique deux parties : le client (l'initiateur de la connexion, généralement un navigateur Web) et le serveur. Le but de la négociation SSL/TLS est d'effectuer tout le travail cryptographique pour établir une connexion sécurisée, y compris la vérification de l'authenticité du certificat SSL utilisé et la génération de la clé de cryptage.

Négociation par numérotation

Chaque logiciel est unique. Par conséquent, même les navigateurs Web les plus populaires ont des fonctionnalités différentes. De même côté serveur – Windows Server, Apache et NGINX sont également différents les uns des autres. Les choses deviennent encore plus compliquées lorsque vous ajoutez des configurations personnalisées.

C'est pourquoi la première étape d'une négociation TLS consiste pour le client et le serveur à échanger des informations sur leurs capacités afin de sélectionner davantage les fonctions cryptographiques prises en charge.

Une fois que le client et le serveur se sont mis d'accord sur la suite de chiffrement à utiliser, le serveur envoie son certificat SSL au client.

Authentification

Après avoir reçu le certificat, le client vérifie son authenticité. Il s’agit d’une étape extrêmement importante. Pour garantir une connexion sécurisée, vous devez non seulement crypter les données, mais vous devez également vous assurer qu'elles sont envoyées au bon site Web. Les certificats SSL/TLS fournissent cette authentification, et la manière dont ils le font dépend de la suite de chiffrement utilisée.

Tous les certificats SSL de confiance sont émis par une autorité de certification (CA). Une autorité de certification doit suivre des règles strictes pour émettre et valider des certificats afin d'être digne de confiance. Vous pouvez considérer une autorité de certification comme un notaire : sa signature signifie que les données contenues dans le certificat sont réelles.

Au cours de la partie authentification de la négociation TLS, le client effectue plusieurs vérifications cryptographiquement sécurisées pour garantir que le certificat émis par le serveur est valide. Le processus implique de vérifier la signature numérique et si le certificat a été émis par une autorité de certification de confiance.

A ce stade, le client vérifie indirectement si le serveur possède la clé privée associée au certificat.

Dans RSA, le système de cryptographie à clé publique le plus largement utilisé, le client utilise la clé publique pour chiffrer les données aléatoires qui seront utilisées pour générer la clé de session. Le serveur ne pourra décrypter et utiliser ces données que s'il dispose d'une clé privée dont la présence garantit l'authenticité de la partie.

Si un autre système de cryptographie est utilisé, l’algorithme peut changer, mais l’authenticité de l’autre partie sera toujours vérifiée.

Échange de clés

La dernière partie de la négociation TLS consiste à créer une « clé de session » qui sera réellement utilisée pour une communication sécurisée.

Les clés de session sont « symétriques », ce qui signifie que la même clé est utilisée pour le chiffrement et le déchiffrement.

Le chiffrement symétrique est plus rapide que le chiffrement asymétrique, ce qui le rend plus adapté à l'envoi de données via une connexion HTTPS. La méthode exacte de génération de clé dépend de la suite de chiffrement choisie, les deux plus courantes étant RSA et Diffie-Hellman.

Pour terminer la poignée de main, chaque partie indique à l'autre qu'elle a effectué tout le travail nécessaire, puis vérifie les sommes de contrôle pour s'assurer que la poignée de main s'est produite sans aucune interférence ni corruption.

L’intégralité de la négociation SSL se déroule en quelques centaines de millisecondes. C'est la première chose qui se produira sur une connexion HTTPS, avant même le chargement de la page Web. Après la négociation SSL, une connexion HTTPS cryptée et authentifiée démarre et toutes les données envoyées et reçues par le client et le serveur sont protégées.

Jusqu'à TLS 1.3, chaque fois que vous visitiez un site, la poignée de main se reproduisait. La poignée de main TLS 1.3 prend en charge 0-RTT, ou temps de reprise aller-retour nul, ce qui augmente considérablement la vitesse du visiteur qui revient.

Processus de prise de contact étape par étape dans TLS 1.2

Examinons de plus près la négociation TLS à l'aide de RSA. L'utilisation de l'algorithme Diffie-Hellman sera décrite ci-dessous.

1. Le premier message s'appelle "Client Bonjour". Ce message répertorie les capacités du client afin que le serveur puisse sélectionner la suite de chiffrement à utiliser pour la communication. Le message comprend également un grand nombre premier sélectionné au hasard appelé « nombre aléatoire du client ».
2. Le serveur répond poliment par un message « Server Hello ». Là, il indique au client quels paramètres de connexion ont été sélectionnés et renvoie son nombre premier sélectionné au hasard, appelé « nombre aléatoire du serveur ». Si le client et le serveur ne partagent pas les mêmes suites de chiffrement, la connexion échoue.
3. Dans le message Certificat, le serveur envoie sa chaîne de certificats SSL au client, y compris les certificats feuilles et intermédiaires. Une fois que le client les reçoit, il effectue plusieurs contrôles pour vérifier le certificat. Le client doit également vérifier que le serveur dispose de la clé privée du certificat, ce qui se produit lors du processus d'échange/génération de clé.
4. Il s'agit d'un message facultatif, requis uniquement pour certaines méthodes d'échange de clés (telles que Diffie-Hellman) qui nécessitent des données supplémentaires de la part du serveur.
5. Le message « Server Hello Done » informe le client que le serveur a fini de transmettre les données.
6. Le client participe ensuite à la création d'une clé de session. Les spécificités de cette étape dépendent de la méthode d'échange de clés choisie dans les messages Hello d'origine. Puisque nous parlons de RSA, le client générera une chaîne d'octets aléatoires appelée secret pré-maître, la chiffrera avec la clé publique du serveur et la renverra.
7. Le message « Modifier les spécifications de chiffrement » informe l'autre partie que la clé de session a été générée et peut passer à une connexion cryptée.
8. Un message « Terminé » est ensuite envoyé, indiquant que la prise de contact est terminée côté client. A partir de ce moment, la connexion est protégée par une clé de session. Le message contient des données (MAC) qui peuvent être utilisées pour vérifier que la prise de contact n'a pas été falsifiée.
9. Le serveur déchiffre désormais le secret pré-maître et calcule la clé de session. Envoie ensuite un message « Modifier les spécifications de chiffrement » pour avertir qu'il passe à une connexion cryptée.
10. Le serveur envoie également un message « Terminé » à l'aide de la clé de session symétrique nouvellement générée et vérifie la somme de contrôle pour vérifier l'intégrité de l'ensemble de la négociation.

Après ces étapes, la négociation SSL est terminée. Les deux parties disposent désormais d’une clé de session et peuvent communiquer via une connexion cryptée et authentifiée.

A ce stade, les premiers octets de l'application web (données liées au service réel - HTML, Javascript, etc.) peuvent être envoyés.

Processus de prise de contact étape par étape dans TLS 1.3

La poignée de main TLS 1.3 est nettement plus courte que celle de son prédécesseur.

1. Comme avec TLS 1.2, le message « Client Hello » initie la prise de contact, mais cette fois il contient beaucoup plus d'informations. TLS 1.3 a réduit le nombre de chiffrements pris en charge de 37 à 5. Cela signifie que le client peut deviner quel accord de clé ou quel protocole d'échange sera utilisé, donc en plus du message, il envoie sa partie de la clé publique à partir du protocole deviné.
2. Le serveur répondra avec un message « Server Hello ». Comme pour le handshake 1.2, un certificat est envoyé à cette étape. Si le client a bien deviné le protocole de cryptage avec les données jointes et que le serveur l'a accepté, ce dernier envoie sa partie de la clé publique, calcule la clé de session et termine la transmission avec le message « Server Finished ».
3. Maintenant que le client dispose de toutes les informations nécessaires, il vérifie le certificat SSL et utilise les deux clés publiques pour calculer sa copie de la clé de session. Lorsque cela est fait, il envoie un message « Client terminé ».

Overhead de la poignée de main TLS

Historiquement, l’une des plaintes concernant SSL/TLS était qu’il surchargeait les serveurs avec une surcharge supplémentaire. Cela a influencé l’idée aujourd’hui disparue selon laquelle HTTPS est plus lent que HTTP.

Les poignées de main avant TLS 1.2 nécessitaient beaucoup de ressources et, à grande échelle, pouvaient sérieusement charger le serveur. Même les poignées de main TLS 1.2 peuvent ralentir si elles sont nombreuses à se produire en même temps. L'authentification, le cryptage et le décryptage sont des processus coûteux.

Sur les petits sites Web, cela n'entraînera probablement pas de ralentissement notable, mais sur les systèmes d'entreprise qui reçoivent des centaines de milliers de visiteurs chaque jour, cela peut constituer un gros problème. Chaque nouvelle version du handshake simplifie considérablement le processus : TLS 1.2 effectue deux phases, tandis que TLS 1.3 s'intègre dans une seule et prend en charge 0-RTT.

Améliorations de la négociation TLS 1.3 par rapport à TLS 1.2

Dans l’explication ci-dessus, la poignée de main est divisée en dix étapes distinctes. En réalité, bon nombre de ces choses se produisent simultanément, c’est pourquoi elles sont souvent regroupées et appelées phases.

La prise de contact TLS 1.2 comporte deux phases. Parfois, des quantités supplémentaires peuvent être nécessaires, mais lorsqu’il s’agit de quantité, le scénario par défaut est optimal.

Contrairement à la version 1.2, la poignée de main TLS 1.3 s'inscrit dans une phase, même s'il serait plus précis de dire une phase et demie, mais elle est toujours nettement plus rapide que TLS 1.2.

Réduction des suites de chiffrement

Personne n’a jamais eu l’intention d’utiliser 37 suites pour chiffrer des données, c’est ainsi que le protocole a évolué. Chaque fois qu'un nouvel algorithme était ajouté, de nouvelles combinaisons étaient ajoutées, et bientôt l'IANA administrait 37 suites de chiffrement différentes.

C'est mauvais pour deux raisons :

1. Cette variabilité conduit à des configurations erronées qui rendent les internautes vulnérables aux exploits connus.
2. Cela a rendu la configuration de SSL plus confuse.

L'IETF a supprimé la prise en charge de tous les algorithmes, sauf les plus sécurisés, dans TLS 1.3, éliminant ainsi toute confusion en limitant le choix. En particulier, le choix de la méthode d'échange de clés a été supprimé. Le schéma éphémère Diffie-Hellman est devenu le seul moyen pour un client d'envoyer ses informations clés ainsi que le « Client Hello » dans la première partie de la poignée de main. Le cryptage RSA a été complètement supprimé, ainsi que tous les autres systèmes d'échange de clés statiques.

Cela étant dit, il existe un talon d'Achille potentiel dans TLS 1.3.

Temps de reprise zéro aller-retour - 0-RTT

0-RTT est ce que réclamait le monde entier de la technologie, et il est désormais disponible avec TLS 1.3. Comme mentionné, la prise de contact TLS a toujours été lente, il était donc important de l'accélérer. 0-RTT fait cela en stockant certaines informations secrètes sur le client, généralement un identifiant de session ou des tickets de session, pour une utilisation lors de la prochaine connexion.

Malgré tous les avantages du 0-RTT, il comporte quelques pièges potentiels. Ce mode rend les clients vulnérables aux attaques par rejeu, dans lesquelles un attaquant qui parvient d'une manière ou d'une autre à accéder à la session chiffrée peut obtenir les données 0-RTT, y compris la première demande du client, et les renvoyer au serveur.

Cependant, l’exploit n’est pas simple à utiliser. Ce risque est probablement un petit prix à payer pour une fonctionnalité extrêmement utile.

Sécurité

Dès le début, la quantité d’informations envoyées en clair lors d’une poignée de main a suscité des inquiétudes. Évidemment, cela n’est pas sécurisé, donc plus il y a d’étapes de négociation chiffrées, mieux c’est.

Dans la poignée de main TLS 1.2, les étapes de négociation n'étaient pas protégées, mais utilisaient plutôt une simple fonction MAC pour garantir que personne n'interférait avec la transmission. La phase de négociation comprend les messages « Client Hello » et « Server Hello ».

La fonction MAC fait office d'indicateur, mais n'apporte aucune garantie de sécurité. Vous avez peut-être entendu parler d'une attaque qui oblige les parties à utiliser des protocoles et des fonctions moins sécurisés (attaque par rétrogradation). Si le serveur et le client prennent en charge des suites de chiffrement obsolètes - des informations à ce sujet peuvent être facilement obtenues en écoutant la connexion - un attaquant peut modifier le cryptage choisi par le serveur pour un cryptage plus faible. De telles attaques ne sont pas dangereuses en elles-mêmes, mais ouvrent la porte à l’utilisation d’autres exploits connus des suites de chiffrement par lesquelles celle d’origine a été modifiée.

La négociation TLS 1.3 utilise une signature numérique dès le début de la connexion, ce qui la rend plus sécurisée et protège contre les attaques par piratage de chiffrement. La signature vous permet également d'authentifier le serveur plus rapidement et plus efficacement.

Voyons maintenant comment ces mises à jour de la négociation TLS 1.3 seront implémentées dans les trois fonctions principales de la négociation SSL/TLS elle-même.

Suites de chiffrement de prise de contact TLS

Une suite de chiffrement est un ensemble d'algorithmes qui déterminent les paramètres d'une connexion sécurisée.

Au début de toute connexion, la toute première interaction, « Client Hello », est une liste des suites de chiffrement prises en charge. Le serveur choisit l'option la meilleure et la plus sécurisée qu'il prend en charge et répond à ses exigences. Vous pouvez consulter la suite de chiffrement et déterminer tous les paramètres de prise de contact et de connexion.

Suites de chiffrement TLS 1.2

• TLS est un protocole.
• ECDHE est un algorithme d'échange de clés.
• ECDSA est un algorithme d'authentification.
• AES 128 GCM est un algorithme de chiffrement symétrique.
• SHA256 est un algorithme de hachage.

L'exemple ci-dessus utilise le système éphémère Elliptic Curve Diffie-Hellman (DH) pour l'échange de clés et l'algorithme de signature numérique Elliptic Curve pour l'authentification. DH peut également être couplé à RSA (fonctionnant comme un algorithme de signature numérique) pour effectuer l'authentification.

Voici une liste des suites de chiffrement TLS 1.2 les plus largement prises en charge :

Suites de chiffrement TLS 1.3

• TLS est un protocole.
• AES 256 GCM est un algorithme de chiffrement authentifié avec données jointes (AEAD).
• SHA384 est l'algorithme de fonction de génération de clé de hachage (HKFD).

Nous savons déjà que nous utiliserons une version de l'échange de clés éphémères Diffie-Hellman, mais nous ne connaissons pas les paramètres, donc les deux premiers algorithmes de la suite de chiffrement TLS 1.2 ne sont plus nécessaires. Ces fonctions fonctionnent toujours, elles n'ont tout simplement plus besoin d'être négociées lors d'une poignée de main.

Dans l'exemple ci-dessus, vous pouvez voir qu'AES (Advanced Encryption Standard) est utilisé pour crypter une grande quantité de données. Il fonctionne en mode compteur Galois à l'aide de clés de 256 bits.

Voici les cinq suites de chiffrement prises en charge dans TLS 1.3 :

• TLS_AES_256_GCM_SHA384 ;
• TLS_CHACHA20_POLY1305_SHA256 ;
• TLS_AES_128_GCM_SHA256 ;
• TLS_AES_128_CCM_8_SHA256 ;
• TLS_AES_128_CCM_SHA256.

Qu'est-ce qui a changé dans TLS 1.3 par rapport à TLS 1.2 ?

Il est important de se rappeler que la version 1.3 a été conçue dans un souci d'amélioration de la sécurité et des performances. Pour y parvenir, dans TLS 1.3, l'algorithme de génération de clé a été repensé et les vulnérabilités connues ont été corrigées.

La prise de contact TLS 1.3 améliore également certains processus, tels que l'authentification des messages et les signatures numériques.

Enfin, en plus de supprimer progressivement les anciens algorithmes de génération ou d’échange de clés, TLS 1.3 élimine les anciens chiffrements symétriques. TLS 1.3 a complètement éliminé les chiffrements par blocs. Le seul type de chiffrement symétrique autorisé dans TLS 1.3 est appelé chiffrement authentifié avec données supplémentaires (AEAD). Il combine le cryptage et l'authentification des messages (MAC) en une seule fonction.

Authentification dans la poignée de main TLS

Historiquement, les deux principales options d'échange de clés sont RSA et Diffie-Hellman (DH). De nos jours, DH est souvent associé à Elliptic Curve Key Exchange (ECDH). Malgré certaines similitudes fondamentales, il existe des différences fondamentales entre ces deux approches de l’échange de clés.

En d’autres termes, la négociation RSA TLS est différente de la négociation ECDH TLS.

RSA utilise la factorisation première et l'arithmétique modulaire. Les grands nombres premiers nécessitent beaucoup de puissance CPU pour être calculés et sont difficiles à trouver.

Diffie-Hellman est parfois appelé échange de clés exponentiel, qui fait référence à l'exponentiation (en plus de l'arithmétique modulaire), mais DH lui-même ne crypte ni ne déchiffre rien du tout. Donc l’appeler « méthode de cryptage » au lieu de « raisonnement mathématique » peut être un peu trompeur.

Une brève excursion dans l’histoire peut clarifier ce point.

En 1976, Whitfield Diffie et Martin Hellman ont créé un protocole d'échange de clés basé sur les travaux de Ralph Merkle, dont le nom, selon tous deux, devrait également apparaître dans le nom du protocole.

Ils ont essayé de résoudre le problème de l'échange sécurisé de clés sur un canal non sécurisé, même si un attaquant l'écoute. Ils ont réussi, mais il y avait un défaut majeur : l’échange de clés DH n’incluait pas d’authentification, il n’y avait donc aucun moyen de vérifier qui était à l’autre bout de la connexion.

Cela peut être considéré comme la naissance de la cryptographie à clé publique et de la PKI. Peu de temps après que Diffie et Hellman ont introduit leur protocole d'échange de clés, les premières versions du cryptosystème RSA ont été achevées. Diffie et Hellman avaient créé le concept de cryptage à clé publique, mais n'avaient pas encore mis au point la fonctionnalité de cryptage unidirectionnel elle-même.

C'est Ron Rivest (R dans RSA) qui a créé le concept qui est finalement devenu le cryptosystème RSA.

À bien des égards, RSA est le successeur spirituel de DH. Il réalise :

• génération de clé ;
• échange de clés ;
• chiffrement;
• décryptage.

Ainsi, RSA est un algorithme plus performant capable de gérer à la fois l’échange de clés et les signatures numériques, c’est-à-dire l’authentification en plus de l’échange de clés sécurisé. RSA dispose donc de clés plus grandes : une sécurité suffisante doit être assurée pour la signature numérique.

Alors que RSA gère l'authentification et l'échange de clés, Diffie-Hellman facilite uniquement l'échange de clés. Il existe quatre variantes courantes de la famille DH :

• Diffie-Hellman (DH);
• éphémère (court terme) Diffie-Hellman (DHE);
• courbe elliptique Diffie-Hellman (ECDH) ;
• Courbe elliptique éphémère Diffie-Hellman (ECDHE).

Encore une fois, Diffie-Hellman à lui seul n’authentifie rien. Il doit être utilisé conjointement avec un algorithme de signature numérique. Ainsi, par exemple, si vous avez utilisé ECDH ou ECDHE, la plupart des suites de chiffrement seront associées à l'algorithme de signature numérique à courbe elliptique (ECDSA) ou RSA.

Authentification dans la poignée de main TLS 1.2

Comme nous venons de le mentionner, la fonctionnalité supplémentaire de RSA pour l'authentification à l'aide de signatures numériques nécessite des clés volumineuses résistantes aux attaques par force brute. La taille de ces clés augmente considérablement le coût de leur calcul, de leur chiffrement et de leur déchiffrement lors d’une poignée de main.

D’un autre côté, si Diffie-Hellman n’effectue pas d’authentification, que fait-il ? Comme mentionné ci-dessus, DH est souvent utilisé en conjonction avec la cryptographie à courbe elliptique pour assurer l'authentification et l'échange de clés.

La cryptographie elliptique (ECC) a des tailles de clé beaucoup plus petites qui correspondent à la courbe elliptique sur laquelle elle est basée. Il existe cinq courbes adaptées à ce contexte :

• 192 bits ;
• 224 bits ;
• 256 bits ;
• 384 bits ;
• 521 bits.

Mais ce n'est pas la seule différence entre les clés publiques/privées ECC et les clés RSA. Ils sont utilisés à deux fins complètement différentes lors d’une poignée de main TLS.

Dans RSA, la paire de clés publique/privée est utilisée à la fois pour l'authentification du serveur et pour l'échange de clés de session symétrique. En fait, c'est l'utilisation réussie du secret pré-maître qui authentifie le serveur.

Avec Diffie-Hellman, la paire de clés publique/privée n'est PAS utilisée pour échanger une clé de session symétrique. Lorsque Diffie-Hellman est impliqué, la clé privée est en fait associée à l'algorithme de signature qui l'accompagne (ECDSA ou RSA).

Authentification RSA

Le processus d'authentification RSA est lié au processus d'échange de clés. Plus précisément, l'échange de clés fait partie du processus d'authentification.

Lorsqu'un client se voit présenter le certificat SSL d'un serveur, il vérifie plusieurs indicateurs :

• signature numérique utilisant une clé publique ;
• une chaîne de certificats pour garantir que le certificat provient de l'un des certificats racines du magasin de confiance ;
• date d'expiration pour s'assurer qu'elle n'a pas expiré ;
• statut de révocation du certificat.

Si toutes ces vérifications ont réussi, le dernier test est effectué : le client crypte le secret pré-maître à l'aide de la clé publique du serveur et l'envoie. N'importe quel serveur peut essayer de faire passer n'importe quel certificat SSL/TLS pour le sien. Après tout, ce sont des certificats publics. Ainsi, le client peut authentifier le serveur en voyant la clé privée « en action ».

Ainsi, si le serveur peut déchiffrer le secret pré-maître et l'utiliser pour calculer la clé de session, il y accède. Cela vérifie que le serveur est le propriétaire de la paire de clés publique/privée utilisée.

Authentification DH

Lorsque Diffie-Hellman et ECDSA/RSA sont utilisés, l'authentification et l'échange de clés fonctionnent côte à côte. Et cela nous ramène aux clés et à leurs utilisations. La clé publique/privée RSA est utilisée à la fois pour l’échange de clés et l’authentification. En DH+ECDSA/RSA, la bi-clé asymétrique est utilisée uniquement pour la phase de signature numérique ou d'authentification.

Lorsque le client reçoit le certificat, il effectue toujours les vérifications standards :

• vérifie la signature sur le certificat,
• chaîne de certificats,
• validité,
• statut de révision.

Mais la propriété d’une clé privée est vérifiée différemment. Lors de l'échange de clé de négociation TLS (étape 4), le serveur utilise sa clé privée pour chiffrer le nombre aléatoire du client et du serveur, ainsi que son paramètre DH. Il agit comme une signature numérique pour le serveur et le client peut utiliser la clé publique associée pour vérifier que le serveur est le propriétaire légitime de la paire de clés.

Authentification dans la poignée de main TLS 1.3

Dans TLS 1.3, l'authentification et les signatures numériques jouent toujours un rôle important, mais elles ont été supprimées des suites de chiffrement pour simplifier la négociation. Ils sont implémentés côté serveur et utilisent plusieurs algorithmes pris en charge par le serveur en raison de leur sécurité et de leur omniprésence. TLS 1.3 autorise trois algorithmes de signature principaux :

• RSA (signature uniquement),
• Algorithme de signature numérique à courbe elliptique (ECDSA),
• Algorithme de signature numérique Edwards (EdDSA).

Contrairement à la prise de contact TLS 1.2, la partie authentification de la prise de contact TLS 1.3 n'est pas associée à l'échange de clé lui-même. Au lieu de cela, il est traité en parallèle avec l'échange de clés et l'authentification des messages.

Au lieu d'exécuter un circuit MAC symétrique pour vérifier l'intégrité de la prise de contact, le serveur signe l'intégralité du hachage de déchiffrement lorsqu'il renvoie un « Server Hello » avec sa partie de la clé partagée.

Le client reçoit toutes les informations transmises par le « Server Hello » et effectue une série standard de vérifications d'authentification de certificat SSL/TLS. Cela implique de vérifier la signature sur le certificat, puis de la comparer à la signature qui a été ajoutée au hachage de déchiffrement.

Une correspondance confirme que le serveur possède la clé secrète.

Échange de clés dans la poignée de main TLS

Si vous mettez en évidence l'idée principale de cette section, cela ressemblera à ceci :

RSA facilite l'échange de clés en permettant au client de chiffrer un secret partagé et de l'envoyer au serveur, où il est utilisé pour calculer la clé de session correspondante. L'échange de clé DH ne nécessite pas du tout d'échange de clé publique, mais les deux parties créent plutôt une clé ensemble.

Si cela semble un peu abstrait maintenant, tout devrait devenir plus clair à la fin de cette section.

Échange de clés RSA

L’appeler échange de clés RSA est en fait un abus de langage. Il s'agit en fait du cryptage RSA. RSA utilise le cryptage asymétrique pour créer la clé de session. Contrairement à DH, la paire de clés publique/privée joue un rôle important.

Voici comment cela se passe :

1. X Et oui
2. Le client génère secret pré-maître(a) puis utilise la clé publique du serveur pour la crypter et l'envoyer au serveur.
3. Le serveur décrypte secret pré-maître en utilisant la clé privée correspondante. Désormais, les deux côtés disposent des trois variables d'entrée et les mélangent avec des fonctions pseudo-aléatoires (PRF) pour créer une clé principale.
4. Les deux parties mélangent la clé principale avec encore plus de PRF et obtiennent des clés de session correspondantes.

Échange de clés DH

Voici comment fonctionne l'ECDH :

1. Le client et le serveur échangent deux nombres premiers ( X Et oui), appelés nombres aléatoires.
2. Un correspondant choisit un numéro secret appelé secret pré-maître(a), et calcule : x un mod y. Envoie ensuite le résultat (A) à l'autre participant.
3. L'autre côté fait de même, choisissant le sien secret pré-maître(b) et calcule x b mod y, puis renvoie sa valeur (B).
4. Les deux parties complètent cette partie en acceptant les valeurs données et en répétant l'opération. On calcule b un mod y, l'autre calcule un b mod y.

Il existe une propriété modulo qui indique que chaque côté recevra la même valeur, qui sera la clé utilisée pour le cryptage symétrique lors de la connexion.

Prise de contact TLS 1.2 pour DH

Maintenant que nous avons appris en quoi DH diffère de RSA, voyons à quoi ressemble une négociation TLS 1.2 basée sur DH.

Encore une fois, il existe de nombreuses similitudes entre ces deux approches. Nous utiliserons ECDHE pour l'échange de clés et ECDSA pour l'authentification.

1. Comme avec RSA, le client commence par un message « Client Hello », qui comprend une liste de suites de chiffrement ainsi que le numéro aléatoire du client.
2. Le serveur répond avec son message « Server Hello », qui inclut la suite de chiffrement sélectionnée et le nombre aléatoire du serveur.
3. Le serveur envoie son certificat SSL. Comme pour la prise de contact RSA TLS, le client effectuera une série de vérifications de l'authenticité du certificat, mais comme DH lui-même ne peut pas authentifier le serveur, un mécanisme supplémentaire est nécessaire.
4. Pour effectuer l'authentification, le serveur prend les nombres aléatoires du client et du serveur, ainsi que le paramètre DH qui servira à calculer la clé de session, et les chiffre avec sa clé privée. Le résultat fera office de signature numérique : le client utilisera la clé publique pour vérifier la signature et que le serveur est le propriétaire légitime de la paire de clés, et répondra avec son propre paramètre DH.
5. Le serveur termine cette phase avec un message "Server Hello Done".
6. Contrairement à RSA, le client n'a pas besoin d'envoyer le secret pré-maître au serveur à l'aide d'un cryptage asymétrique ; le client et le serveur utilisent plutôt les paramètres DH qu'ils ont échangés précédemment pour obtenir le secret pré-maître. Tout le monde utilise ensuite le secret pré-maître qu'il vient de calculer pour obtenir la même clé de session.
7. Le client envoie un message « Change Cipher Spec » pour informer l'autre partie qu'il passe au cryptage.
8. Le client envoie un message final « Terminé » pour indiquer qu'il a terminé sa partie de la prise de contact.
9. De même, le serveur envoie un message « Change Cipher Spec ».
10. La poignée de main se termine par un message « Terminé » du serveur.

Avantages du DHE par rapport au RSA

Il y a deux raisons principales pour lesquelles la communauté des cryptographes préfère utiliser DHE plutôt que RSA : une confidentialité parfaite et des vulnérabilités connues.

Secret de transfert parfait

Vous vous êtes peut-être déjà demandé ce que signifie le mot « éphémère » à la fin de DHE et ECDHE. Éphémère signifie littéralement « de courte durée ». Et cela peut aider à comprendre le Perfect Forward Secrecy (PFS), qui est une caractéristique de certains protocoles d’échange clés. PFS garantit que les clés de session échangées entre les parties ne peuvent pas être compromises, même si la clé privée du certificat est compromise. En d’autres termes, il protège les sessions précédentes de l’extraction et du décryptage. PFS a reçu la priorité absolue après la découverte du bug Heartbleed. Il s'agit d'un composant essentiel de TLS 1.3.

Vulnérabilité d'échange de clés RSA

Il existe des vulnérabilités qui peuvent exploiter le remplissage ( rembourrage), utilisé lors de l'échange de clés dans les anciennes versions de RSA (PKCS #1 1.5). C'est un aspect du cryptage. Avec RSA, le secret pré-maître doit être chiffré avec la clé publique et déchiffré avec la clé privée. Mais lorsque ce secret pré-maître plus petit est placé dans une clé publique plus grande, il doit être complété. Dans la plupart des cas, si vous essayez de deviner le contenu et d'envoyer une fausse demande au serveur, vous vous tromperez, celui-ci reconnaîtra l'écart et le filtrera. Mais il y a de fortes chances que vous puissiez envoyer suffisamment de requêtes au serveur pour deviner le bon remplissage. Ensuite, le serveur enverra un message complété par erreur, ce qui réduira à son tour la valeur possible du secret pré-maître. Cela permettra à un attaquant de calculer et de compromettre la clé.

C'est pourquoi RSA a été supprimé au profit de DHE dans TLS 1.3.

Échange de clés dans la poignée de main TLS 1.3

Dans une prise de contact TLS 1.3, en raison du choix limité de schémas d'échange de clés, un client peut réussir à deviner le schéma et envoyer sa partie de la clé partagée pendant la phase initiale (Client Hello) de la prise de contact.

RSA n'était pas le seul système d'échange de clés supprimé dans TLS 1.3. Les schémas Diffie-Hellman non éphémères ont également été éliminés, tout comme la liste des paramètres Diffie-Hellman insuffisamment sécurisés.

Qu'entendez-vous par paramètres insuffisamment sécurisés ? Sans entrer dans trop de mathématiques, la complexité de Diffie-Hellman et de la plupart des cryptosystèmes à clé publique réside dans la complexité de la résolution de problèmes de logarithme discret. Le cryptosystème doit être suffisamment complexe pour pouvoir calculer si les paramètres d'entrée (nombres aléatoires du client et du serveur) sont inconnus, sinon l'ensemble du système sera inutile. Les schémas Diffie-Hellman, qui ne pouvaient pas fournir des paramètres suffisamment grands, ont été éliminés dans TLS 1.3.

1. Au début d'une négociation TLS 1.3, sachant que le schéma d'accord de clé DHE sera utilisé, le client inclut sa partie de la clé partagée basée sur le schéma d'échange de clé prévu dans son message « Client Hello ».
2. Le serveur reçoit cette information et, si le client a raison, renvoie sa part de clé publique dans un « Server Hello ».
3. Le client et le serveur calculent la clé de session.

Ceci est très similaire à ce qui se passe avec DH dans une poignée de main TLS 1.2, sauf que dans TLS 1.3, l'échange de clé a lieu plus tôt.

Au lieu d'une conclusion

La prise de contact SSL/TLS est un processus fascinant qui est essentiel à un Internet sécurisé, et pourtant il se produit si rapidement et de manière si transparente que la plupart des gens n'y pensent même pas.

Au moins jusqu'à ce que quelque chose tourne mal.

Les protocoles réseau SSL et TLS sont des protocoles cryptographiques qui assurent l'authentification et la protection contre les accès non autorisés et la violation de l'intégrité des données transmises. Les protocoles SSL/TLS sont conçus pour empêcher l'usurpation d'identifiant côté client ou serveur, la divulgation ou la corruption de données. À ces fins, une méthode d'authentification fiable est utilisée, le cryptage des canaux de communication et les codes d'intégrité des messages sont utilisés. Le port standard par défaut pour SSL/TLS est 443 pour HTTPS, 465 pour SMTPS (e-mail), 636 pour LDAPS, 563 pour NNTPS, 994 pour IRCS (chat), 995 pour POP3S.

Protocole SSL

Le protocole SSL a été développé par Netscape pour protéger les données entre les protocoles de service et de transport. La première version publique est sortie en 1995. Largement utilisé pour les applications VoIP, les services de messagerie instantanée. SSL est un canal sécurisé qui possède les propriétés suivantes :

• Chaîne privée. Garantit que tous les messages sont cryptés après le dialogue requis pour déterminer la clé de cryptage.
• La chaîne est authentifiée. L'authentification est facultative côté client, mais obligatoire côté serveur.
• Fiabilité des canaux. Lorsque les messages sont transportés, des contrôles d'intégrité sont effectués à l'aide de MAC.

Le protocole SSL utilise des clés symétriques et asymétriques.

Caractéristiques et objectif du protocole SSL

Le protocole SSL apporte une solution à deux problèmes : le cryptage des informations transmises et le transfert des informations exactement là où elles sont requises (authentification). L'objectif principal du protocole est de fournir un moyen fiable d'échanger des données entre applications. La mise en œuvre de SSL se fait sous la forme d'un environnement multicouche, utilisé pour la transmission sécurisée d'informations via des canaux de communication non sécurisés.

La structure multicouche est représentée par une couche de protocole de confirmation de connexion et une couche de protocole d'enregistrement. La première couche est un protocole de transport, par exemple TCP - avec le SSL Record Protocol, ces couches forment le cœur de SSL, qui participe ensuite à la formation d'infrastructures complexes.

Parmi les principales caractéristiques du protocole SSL, il convient de noter l'indépendance de la plate-forme logicielle. Actuellement, le protocole SSL n'offre pas une sécurité adéquate : il a été remplacé par le protocole TLS.

Protocole TLS

Le protocole TLS est un protocole cryptographique utilisé pour sécuriser le transfert de données entre différents nœuds sur Internet. Ce protocole est utilisé dans les applications VoIP, les navigateurs Web et les applications de messagerie instantanée. TLS est implémenté sur la base de la spécification SSL 3.0. Le protocole est en cours d'élaboration et de développement par l'IETF.

Les principales mesures de sécurité fournies par le protocole TLS comprennent :

• Utilisation d'une clé pour vérifier le code d'authentification du message.
• La possibilité de rétrograder la version TLS ou de la remplacer par un protocole réseau moins sécurisé est éliminée.
• Le message de prise de contact contient un hachage de tous les messages échangés entre les parties.
• Utilisation de la numérotation des enregistrements d'application à l'aide de MAC.
• L'utilisation d'une fonction pseudo-aléatoire qui divise les messages d'entrée en 2 parties, chacune étant traitée par une fonction de hachage différente.

Caractéristiques et objectif du protocole TLS

Le protocole TLS utilise les algorithmes suivants :

• RC4, Triple DES, SEED, IDEA, etc. pour un cryptage symétrique.
• RSA, DSA, Diffie-Hellman et ECDSA pour l'authentification par clé.
• MD5, SHA et SHA-256/384 pour les fonctions de hachage.

Les applications échangent des enregistrements qui stockent des données. Les enregistrements peuvent être compressés, augmentés, cryptés ou identifiés. Dans ce cas, chaque entrée indique la longueur du paquet et la version TLS utilisée.

En général, l'utilisation de la cryptographie dans les protocoles SSL/TLS réduit considérablement les performances des applications, mais assure une sécurité fiable de la transmission des données. Les protocoles ne nécessitent pratiquement aucun réglage côté client et sont considérés comme les protocoles de sécurité les plus courants sur Internet.

Tous nos arguments reposent sur le fait que le système d'exploitation est Windows XP ou version ultérieure (Vista, 7 ou 8), sur lequel sont installées toutes les mises à jour et correctifs appropriés. Il y a maintenant une condition supplémentaire : nous parlons des dernières versions des navigateurs, et non d'un « Ognelis sphérique dans le vide ».

Nous configurons donc les navigateurs pour qu'ils utilisent les dernières versions du protocole TLS et n'utilisent pas du tout ses versions obsolètes et SSL. Du moins, dans la mesure du possible en théorie.

Et la théorie nous dit que même si Internet Explorer prend déjà en charge TLS 1.1 et 1.2 à partir de la version 8, sous Windows XP et Vista, nous ne le forcerons pas à le faire. Cliquez : Outils/Options Internet/Avancé et dans la rubrique « Sécurité » on trouve : SSL 2.0, SSL 3.0, TLS 1.0... avez-vous trouvé autre chose ? Félicitations, vous aurez TLS 1.1/1.2 ! S'ils ne l'ont pas trouvé, vous avez Windows XP ou Vista, et à Redmond, ils vous considèrent comme un attardé.

Alors décochez toutes les cases SSL, cochez toutes les cases TLS disponibles. Si seul TLS 1.0 est disponible, qu'il en soit ainsi ; si des versions plus récentes sont disponibles, il est préférable de ne les sélectionner que et de décocher TLS 1.0 (et de ne pas s'étonner plus tard que certains sites ne s'ouvrent pas via HTTPS). Cliquez ensuite sur les boutons « Appliquer » et « OK ».

C'est plus simple avec Opera, cela nous offre un véritable banquet de différentes versions de protocoles : Outils/Paramètres généraux/Avancé/Sécurité/Protocole de sécurité. Que voit-on ? L'ensemble, à partir duquel nous laissons les cases à cocher uniquement pour TLS 1.1 et TLS 1.2, après quoi nous cliquons sur le bouton "Détails" et là nous décochons toutes les lignes sauf celles qui commencent par "256 bit AES" - elles sont au tout fin. Au début de la liste il y a une ligne « 256 bits AES ( Anonyme DH/SHA-256), décochez-la également. Cliquez sur « OK » et profitez de la sécurité.

Cependant, Opera a une propriété étrange : si TLS 1.0 est activé, alors s'il est nécessaire d'établir une connexion sécurisée, il utilise immédiatement cette version du protocole, que le site prenne ou non en charge les versions plus récentes. Pourquoi s’embêter – tout va bien, tout est protégé. Lorsque seuls TLS 1.1 et 1.2 sont activés, la version la plus avancée sera tentée en premier, et ce n'est que si elle n'est pas prise en charge par le site que le navigateur passera à la version 1.1.

Mais le sphérique Ognelis Firefox ne nous plaira pas du tout : Outils/Paramètres/Avancé/Chiffrement : on ne peut que désactiver SSL, TLS n'est disponible qu'en version 1.0, il n'y a rien à faire - on le laisse avec une coche.

Cependant, le pire s'apprend par comparaison : Chrome et Safari ne contiennent aucun paramètre sur le protocole de cryptage à utiliser. À notre connaissance, Safari ne prend pas en charge les versions TLS plus récentes que la 1.0 dans les versions pour le système d'exploitation Windows, et puisque la publication de nouvelles versions pour ce système d'exploitation a été interrompue, ce ne sera pas le cas.

Chrome, à notre connaissance, prend en charge TLS 1.1, mais, comme dans le cas de Safari, nous ne pouvons pas refuser l'utilisation de SSL. Il n'existe aucun moyen de désactiver TLS 1.0 dans Chrome. Mais avec l'utilisation réelle de TLS 1.1, une grande question se pose : il a d'abord été activé, puis désactivé en raison de problèmes de fonctionnement et, pour autant que l'on puisse en juger, n'a pas encore été réactivé. Autrement dit, il semble y avoir un support, mais il semble être désactivé et il n'y a aucun moyen pour l'utilisateur de le réactiver. La même histoire est avec Firefox - il prend en charge TLS 1.1, mais il n'est pas encore disponible pour l'utilisateur.

Résumé de la multilettre ci-dessus. Quels sont les dangers généraux liés à l’utilisation de versions obsolètes de protocoles de chiffrement ? Le fait que quelqu'un d'autre accédera à votre connexion sécurisée au site et aura accès à toutes les informations « là-bas » et « là-bas ». Concrètement, il aura un accès complet à sa boîte email, à son compte dans le système client-banque, etc.

Il est peu probable que vous pénétriez accidentellement dans la connexion sécurisée de quelqu'un d'autre, nous parlons uniquement d'actions malveillantes. Si la probabilité de telles actions est faible ou si les informations transmises via une connexion sécurisée ne sont pas particulièrement précieuses, vous n'avez pas à vous soucier d'utiliser des navigateurs qui ne prennent en charge que TLS 1.0.

Sinon, il n'y a pas de choix : uniquement Opera et uniquement TLS 1.2 (TLS 1.1 n'est qu'une amélioration de TLS 1.0, héritant en partie de ses problèmes de sécurité). Cependant, nos sites préférés peuvent ne pas prendre en charge TLS 1.2 :(

Le protocole SSL TLS sécurise les connexions Internet via HTTP (pour les pages Internet), FTP (gestionnaire de fichiers), IMAP, POP3 et SMTP (protocoles de messagerie).

En 2014, une vulnérabilité a été découverte dans SSL et elle a commencé à devenir obsolète, c'est pourquoi la norme TLS a été créée sur la base de SSL 3.0.

TLS(Anglais : Transport Layer Security) est un protocole cryptographique qui permet un transfert sécurisé de données du serveur au client. TLS est basé sur un cryptage symétrique pour la confidentialité, une cryptographie asymétrique pour l'authentification et des codes d'authentification pour préserver l'intégrité des informations transmises. Il prend en compte les erreurs de son prédécesseur et poursuit son développement.

Essentiellement, les différences dans les principes de fonctionnement de SSL et de TLS sont minimes, donc lorsqu'ils parlent de SSL, ils parlent de TLS.

Comment fonctionne TLS

Le processus TLS peut être divisé en plusieurs étapes :

• Poignée de main TLS
• Faux départ TLS
• Chaîne de confiance TLS

Poignée de main TLS— négocie les paramètres de connexion entre le client et le serveur (méthode de cryptage, version du protocole) et vérifie également les certificats. Cette procédure utilise une grande quantité de ressources informatiques, donc, afin de ne pas établir à chaque fois une nouvelle connexion et de ne pas vérifier à nouveau les certificats, la procédure TLS False Start a été développée.

Faux départ TLS— procédure de reprise d'une session. Si une session a été précédemment ouverte entre le client et le serveur, cette étape permet de sauter la procédure Handshake, en utilisant les données configurées précédemment. Cependant, pour des raisons de sécurité, chaque session a sa propre durée de vie et, si elle expire, elle sera rouverte via la procédure TLS Handshake.

Chaîne de confiance TLS— procédure de connexion TLS obligatoire. Il assure l'authentification entre le client et le serveur. Il repose sur une « chaîne de confiance », qui s’appuie sur des certificats d’authenticité délivrés par les Autorités de Certification. L'autorité de certification vérifie l'authenticité du certificat et, s'il est compromis, les données sont révoquées. Grâce à cette procédure, l'authenticité des données transmises est vérifiée.

Ainsi, lors de la transmission de données, on appelle d'abord la procédure TLS Handshake ou TLS False Start, qui négocie les paramètres, puis la TLS Chain of trust, qui assure l'authentification (vérification de la paternité des informations transmises).

Vous pouvez en savoir plus sur le fonctionnement de TLS dans la documentation officielle de Datatracker.

Paramètres de sécurité TLS

• La version TLS ne peut pas être rétrogradée vers une version précédente (moins sécurisée), ni basculée vers un algorithme de chiffrement non sécurisé.
• Les enregistrements de demande consécutives sont numérotés et le numéro de séquence est utilisé dans le code d'authentification du message.
• Seul le propriétaire de la clé peut générer le code d'authentification du message.
• Le message qui termine la poignée de main est utilisé pour confirmer l'authenticité des messages envoyés précédemment.

Installation de SSL/TLS

Sur le site Web de l'entreprise, vous pouvez en sélectionner et en acheter un qui fonctionne avec TLS 1.2 :

Une fois le certificat émis, installez-le vous-même selon l'une des instructions.

Si vous rencontrez un problème d'échec d'accès à un site spécifique et qu'un message apparaît dans votre navigateur, il existe une explication raisonnable à cela. Les causes et les solutions au problème sont présentées dans cet article.

Protocole SSL TLS

Les utilisateurs des organismes budgétaires, et pas seulement budgétaires, dont les activités sont directement liées à la finance, en interaction avec les organismes financiers, par exemple le Ministère des Finances, le Trésor, etc., effectuent toutes leurs opérations exclusivement en utilisant le protocole sécurisé SSL. Fondamentalement, dans leur travail, ils utilisent le navigateur Internet Explorer. Dans certains cas - Mozilla Firefox.

Erreur SSL

La principale attention lors de la réalisation de ces opérations, et des travaux en général, est portée au système de sécurité : certificats, signatures électroniques. La version actuelle du logiciel CryptoPro est utilisée pour le fonctionnement. Concernant problèmes avec les protocoles SSL et TLS, Si Erreur SSL est apparu, il est fort probable qu'il n'y ait aucun support pour ce protocole.

Erreur TLS

Erreur TLS dans de nombreux cas, cela peut également indiquer un manque de prise en charge du protocole. Mais... voyons ce qui peut être fait dans ce cas.

Prise en charge des protocoles SSL et TLS

Ainsi, lorsque vous utilisez Microsoft Internet Explorer pour visiter un site Web sécurisé par SSL, la barre de titre affiche Assurez-vous que les protocoles SSL et TLS sont activés. Tout d'abord, vous devez activer la prise en charge du protocole TLS 1.0 dans Internet Explorer.

Si vous visitez un site Web qui exécute Internet Information Services 4.0 ou version ultérieure, la configuration d'Internet Explorer pour prendre en charge TLS 1.0 permet de sécuriser votre connexion. Bien entendu, à condition que le serveur Web distant que vous essayez d’utiliser prenne en charge ce protocole.

Pour ce faire dans le menu Service choisis une équipe options Internet.

Sur l'onglet En plus Au chapitre Sécurité, assurez-vous que les cases suivantes sont cochées :

• Utilisez SSL 2.0
• Utiliser SSL 3.0
• Utiliser SSL 1.0

Cliquez sur le bouton Appliquer , et puis D'ACCORD . Redémarrez votre navigateur .

Après avoir activé TLS 1.0, essayez à nouveau de visiter le site Web.

Politique de sécurité du système

S'ils surviennent encore erreurs avec SSL et TLS Si vous ne pouvez toujours pas utiliser SSL, le serveur Web distant ne prend probablement pas en charge TLS 1.0. Dans ce cas, vous devez désactiver la stratégie système qui nécessite des algorithmes compatibles FIPS.

Pour ce faire, dans Panneaux de contrôle sélectionner Administration, puis double-cliquez Stratégie de sécurité locale.

Dans Paramètres de sécurité locaux, développez Politiques locales puis cliquez sur le bouton Les paramètres de sécurité.

Selon la politique sur le côté droit de la fenêtre, double-cliquez Cryptographie du système : utilisez des algorithmes conformes à la norme FIPS pour le chiffrement, le hachage et la signature. puis cliquez sur le bouton Désactivé.

Attention!

La modification prend effet lorsque la stratégie de sécurité locale est réappliquée. Allumez-le et redémarrez votre navigateur.

CryptoPro TLS SSL

Mettre à jour CryptoPro

L'une des options pour résoudre le problème consiste à mettre à jour CryptoPro et à configurer la ressource. Dans ce cas, il s’agit de paiements électroniques. Accédez à Autorité de certification. Sélectionnez Marchés électroniques comme ressource.

Après avoir démarré la configuration automatique du poste de travail, il ne reste plus que attendre la fin de la procédure, alors recharger le navigateur. Si vous devez saisir ou sélectionner une adresse de ressource, sélectionnez celle dont vous avez besoin. Vous devrez peut-être également redémarrer votre ordinateur une fois l'installation terminée.