Protocole TLS dans Internet Explorer. Assurez-vous que les protocoles SSL et TLS sont activés. Connexion TLS

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 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 le monde entier de la technologie réclamait, et il est désormais là 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 prise de contact 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.

Description

TLS permet aux applications client-serveur de communiquer sur un réseau de manière à empêcher les écoutes clandestines et les accès non autorisés.

Puisque la plupart des protocoles de communication peuvent être utilisés avec ou sans TLS (ou SSL), lors de l'établissement d'une connexion, vous devez indiquer explicitement au serveur si le client souhaite installer TLS. Ceci peut être réalisé soit en utilisant un numéro de port uniforme sur lequel la connexion est toujours établie à l'aide de TLS (comme le port 443 pour HTTPS), soit en utilisant un port arbitraire et une commande spéciale au serveur du côté client pour changer la connexion. vers TLS en utilisant un protocole de mécanismes spéciaux (tels que STARTTLS pour les protocoles de messagerie). Une fois que le client et le serveur ont accepté d'utiliser TLS, ils doivent établir une connexion sécurisée. Cela se fait à l’aide d’une procédure de prise de contact. Couches de socket sécurisées). Au cours de ce processus, le client et le serveur conviennent de divers paramètres nécessaires pour établir une connexion sécurisée.

Il existe également des variantes d’attaque basées directement sur l’implémentation logicielle du protocole, et non sur son algorithme.

Procédure de prise de contact TLS en détail

Selon le protocole TLS, les applications échangent des enregistrements qui encapsulent (stockent en elles) les informations qui doivent être transmises. Chacune des entrées peut être compressée, complétée, cryptée ou identifiée par un MAC (Message Authentication Code) en fonction de l'état actuel de la connexion (état du protocole). Chaque entrée TLS contient les champs suivants : type de contenu (définit le type de contenu de l'entrée), un champ indiquant la longueur du paquet et un champ indiquant la version du protocole TLS.

Lorsque la connexion est établie pour la première fois, l'interaction se produit à l'aide du protocole de prise de contact TLS, type de contenu qui est 22.

Poignée de main simple en TLS

1. Phase de négociation :
   • Le client envoie un message ClientBonjour
   • Le serveur répond avec un message ServeurBonjour
   • Le serveur envoie un message Certificat
   • Le serveur envoie un message ServeurBonjourTerminé
   • Le client répond par un message ClientKeyExchange, qui contient la clé publique de PreMasterSecret (Ce PreMasterSecret est crypté à l'aide de la clé publique du certificat du serveur.) ou rien (cela dépend encore une fois de l'algorithme de cryptage) ;
   • PréMasterSecret
2. Le client envoie un message ChangeCipherSpec
   • Le client envoie un message Fini
3. Le serveur envoie ChangeCipherSpec

Prise de contact avec authentification du client

Cet exemple illustre l'authentification complète du client (en plus de l'authentification du serveur comme dans l'exemple précédent) en échangeant des certificats entre le serveur et le client.

1. Phase de négociation :
   • Le client envoie un message ClientBonjour, indiquant la dernière version du protocole TLS pris en charge, un nombre aléatoire et une liste des méthodes de cryptage et de compression prises en charge adaptées au travail avec TLS ;
   • Le serveur répond avec un message ServeurBonjour, contenant : la version du protocole sélectionnée par le serveur, un nombre aléatoire envoyé par le client, un algorithme de chiffrement et de compression adapté parmi la liste fournie par le client ;
   • Le serveur envoie un message Certificat, qui contient le certificat numérique du serveur (selon l’algorithme de chiffrement, cette étape peut être ignorée) ;
   • Le serveur envoie un message Demande de certificat, qui contient une demande de certificat client pour une authentification mutuelle ;
   • [Le point d'obtention et de vérification du certificat client est manquant] ;
   • Le serveur envoie un message ServeurBonjourTerminé, identifiant la fin de la poignée de main ;
   • Le client répond par un message ClientKeyExchange, qui contient la clé publique PreMasterSecret ou rien (encore une fois en fonction de l'algorithme de cryptage) ;
   • Client et serveur utilisant la clé PréMasterSecret et des nombres générés aléatoirement, une clé secrète partagée est calculée. Toutes les autres informations clés seront dérivées de la clé secrète partagée (et des valeurs aléatoires générées par le client et le serveur) ;
2. Le client envoie un message ChangeCipherSpec, qui indique que toutes les informations ultérieures seront cryptées à l'aide de l'algorithme établi lors du processus de prise de contact, à l'aide d'une clé secrète partagée. Il s'agit de messages de niveau enregistrement et sont donc de type 20 au lieu de 22 ;
   • Le client envoie un message Fini, qui contient le hachage et le MAC générés à partir des messages de prise de contact précédents ;
   • Le serveur tente de déchiffrer le message Terminé du client et de vérifier le hachage et le MAC. Si le processus de décryptage ou de vérification échoue, la prise de contact est considérée comme ayant échoué et la connexion doit être interrompue.
3. Le serveur envoie ChangeCipherSpec et le message chiffré Terminé, et à son tour, le client effectue également le décryptage et la vérification.

A partir de ce moment, la confirmation de la communication est considérée comme terminée, le protocole est établi. Tous les contenus des paquets suivants sont de type 23 et toutes les données seront cryptées.

Reprise d'une connexion TLS

Les algorithmes de chiffrement asymétrique utilisés pour générer la clé de session sont généralement coûteux en termes de puissance de calcul. Afin d'éviter de les répéter lors de la reprise de la connexion, TLS crée un raccourci spécial lors de la prise de contact qui est utilisé pour reprendre la connexion. Dans ce cas, lors d'une confirmation normale de communication, le client ajoute au message ClientBonjour identifiant de session précédente ID de session. Le client lie l'ID ID de session avec l'adresse IP du serveur et le port TCP afin que lors de la connexion au serveur, vous puissiez utiliser tous les paramètres de la connexion précédente. Le serveur correspond à l'ID de session précédente ID de session avec des paramètres de connexion, tels que l'algorithme de cryptage utilisé et le secret principal. Les deux parties doivent avoir le même secret principal, sinon la connexion ne sera pas établie. Cela empêche l'utilisation ID de session cryptanalyste pour obtenir un accès non autorisé. Séquences de nombres aléatoires dans les messages ClientBonjour Et ServeurBonjour permettent de garantir que la clé de session générée sera différente de la clé de session lors de la connexion précédente. La RFC appelle ce type de poignée de main abrégé.

1. Phase de négociation :
   • Le client envoie un message ClientBonjour, indiquant la dernière version du protocole TLS pris en charge, un nombre aléatoire et une liste des méthodes de cryptage et de compression prises en charge adaptées au travail avec TLS ; L'identifiant de connexion précédent est également ajouté au message. ID de session.
   • Le serveur répond avec un message ServeurBonjour, contenant : la version du protocole sélectionnée par le serveur, un nombre aléatoire envoyé par le client, un algorithme de chiffrement et de compression adapté parmi la liste fournie par le client. Si le serveur reconnaît l'ID de session ID de session ServeurBonjour le même identifiant ID de session. C'est un signal au client que la reprise de la session précédente peut être utilisée. Si le serveur ne reconnaît pas l'ID de session ID de session, puis il ajoute au message ServeurBonjour un autre sens à la place ID de session. Pour le client, cela signifie que la connexion renouvelée ne peut pas être utilisée. Ainsi, le serveur et le client doivent avoir le même secret principal et les mêmes nombres aléatoires pour générer une clé de session ;
2. Le client envoie un message ChangeCipherSpec, ce qui indique que toutes les informations ultérieures seront chiffrées avec la clé secrète partagée établie lors du processus d'établissement de liaison. Il s'agit de messages de niveau enregistrement et sont donc de type 20 au lieu de 22 ;
3. Le client envoie un message ChangeCipherSpec, qui indique que toutes les informations ultérieures seront cryptées à l'aide de l'algorithme établi lors du processus de prise de contact, à l'aide d'une clé secrète partagée. Il s'agit de messages de niveau enregistrement et sont donc de type 20 au lieu de 22 ;
   • Le client envoie un message Fini, qui contient le hachage et le MAC générés à partir des messages de prise de contact précédents ;
   • Le serveur tente de déchiffrer le message Terminé du client et de vérifier le hachage et le MAC. Si le processus de décryptage ou de vérification échoue, la prise de contact est considérée comme ayant échoué et la connexion doit être interrompue ;
4. Le serveur envoie ChangeCipherSpec et le message chiffré Terminé, et à son tour, le client effectue également le décryptage et la vérification.

A partir de ce moment, la confirmation de la communication est considérée comme terminée, le protocole est établi. Tous les contenus des paquets suivants sont de type 23 et toutes les données seront cryptées.

En plus des avantages en termes de performances, l'algorithme de renouvellement de connexion peut être utilisé pour mettre en œuvre l'authentification unique, car il est garanti que la session d'origine et toute session reprise sont initiées par le même client (RFC 5077). Ceci est particulièrement important pour la mise en œuvre de FTP sur TLS/SSL, qui serait autrement vulnérable à une attaque de l'homme du milieu dans laquelle un attaquant pourrait intercepter le contenu des données lorsqu'une reconnexion est établie.

Algorithmes utilisés dans TLS

Les algorithmes suivants sont disponibles dans cette version actuelle du protocole :

• Pour échanger des clés et vérifier leur authenticité, des combinaisons d'algorithmes sont utilisées : RSA (chiffrement asymétrique), Diffie-Hellman (échange sécurisé de clés), DSA (algorithme de signature numérique) et algorithmes de technologie Fortezza ;
• Pour le cryptage symétrique : RC2, RC4, IDEA, DES, Triple DES ou AES ;

Les algorithmes peuvent être complétés en fonction de la version du protocole.

Comparaison avec des analogues

Une application d'une connexion TLS consiste à connecter des hôtes dans un réseau privé virtuel. En plus de TLS, un ensemble de protocoles IPSec et une connexion SSH peuvent également être utilisés. Chacune de ces approches de mise en œuvre d'un réseau privé virtuel présente ses propres avantages et inconvénients. .

1. TLS/SSL
   • Avantages :
     • Invisible pour les protocoles de niveau supérieur ;
     • Utilisation populaire dans les connexions Internet et les applications de commerce électronique ;
     • Manque de connexion permanente entre le serveur et le client ;
     • TCP/IP tel que le courrier électronique, les outils de programmation, etc.
   • Défauts:
     • UDP et ICMP ;
     • La nécessité de surveiller l'état de la connexion ;
     • Il existe des exigences logicielles supplémentaires pour la prise en charge de TLS.
2. IPsec
   • Avantages :
     • La sécurité et la fiabilité de la protection des données du protocole ont été testées et prouvées depuis que le protocole a été adopté comme standard Internet ;
     • Travaillez dans la couche supérieure du protocole réseau et chiffrez les données au-dessus de la couche de protocole réseau.
   • Défauts:
     • Complexité de mise en œuvre ;
     • Exigences supplémentaires pour les équipements réseau (routeurs, etc.) ;
     • Il existe de nombreuses implémentations différentes qui n’interagissent pas toujours correctement les unes avec les autres.
3. SSH
   • Avantages :
     • Permet de créer un tunnel pour les applications qui utilisent TCP/IP, telles que la messagerie électronique, les outils de programmation, etc. ;
     • La couche de sécurité est invisible pour l'utilisateur.
   • Défauts:
     • Difficile à utiliser sur des réseaux comportant un grand nombre de passerelles, comme des routeurs ou des pare-feu ;
     • Impossibilité d'utiliser les protocoles UDP et ICMP.

voir également

Liens

1. T. Dierks, E. Rescorla Le protocole Transport Layer Security (TLS), version 1.2 (août 2008). Archivé de l'original le 9 février 2012.
2. Le protocole SSL : version 3.0 Version finale de Netscape SSL 3.0 (18 novembre 1996)
3. "SSL/TLS en détail" . Microsoft TechNet. Mis à jour le 31 juillet 2003.
4. Dan Goodin . Le registre(19 septembre 2011). Archivé
5. Éric Rescorla Comprendre l'attaque de renégociation TLS. Des conjectures instruites(5 novembre 2009). Archivé de l'original le 9 février 2012. Récupéré le 7 décembre 2011.
6. McMillan, Robert. Security Pro affirme qu'une nouvelle attaque SSL peut toucher de nombreux sites, PC World(20 novembre 2009). Récupéré le 7 décembre 2011.
7. SSL_CTX_set_options SECURE_RENEGOTIATION . Documents OpenSSL(25 février 2010). Archivé de l'original le 9 février 2012. Récupéré le 7 décembre 2010.
8. GnuTLS 2.10.0 est sorti. Notes de version de GnuTLS(25 juin 2010). Archivé de l'original le 9 février 2012. Récupéré le 7 décembre 2011.
9. Notes de version NSS 3.12.6. Notes de version NSS(3 mars 2010). Récupéré le 24 juillet 2011.
10. Divers Vulnérabilité SSL d’IE. Des conjectures instruites(10 août 2002).

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 :(

Selon les exigences de la législation russe, seule l'utilisation de connexions TLS établies selon les algorithmes cryptographiques russes GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 et GOST R 34.10-2001 est reconnue. Par conséquent, si vous devez utiliser des sites utilisant le cryptage selon les algorithmes GOST, vous devez installer le programme CryptoPro CSP.

Les systèmes d'exploitation Windows utilisent le programme CryptoPro CSP - un ensemble d'utilitaires cryptographiques pour générer des signatures électroniques et travailler avec des certificats

Pour installer CryptoPro CSP, utilisez les documents du site officiel :

Après avoir installé CryptoPro CSP, le navigateur vérifie la présence et la fonctionnalité de ce programme.

Sites demandant le cryptage GOST TLS

Si un site demande le cryptage GOST TLS, le navigateur vérifie si le programme CryptoPro CSP est installé. Si le programme est installé, le contrôle lui est transféré.

Exemples de sites demandant le cryptage : www.gosuslugi.ru, sites du domaine .gov.ru, .kamgov.ru, .nalog.ru.

Si le site ne figure pas dans la liste, une confirmation supplémentaire est demandée. Si vous faites confiance au site et que la connexion doit être établie à l'aide du cryptage GOST TLS, cliquez sur le bouton Continuer.

TLS est le successeur de SSL, un protocole qui fournit une connexion fiable et sécurisée entre les nœuds sur Internet. Il est utilisé dans le développement de divers clients, notamment des navigateurs et des applications client-serveur. Qu’est-ce que TLS dans Internet Explorer ?

Un peu de technologie

Toutes les entreprises et organisations qui effectuent des transactions financières utilisent ce protocole pour empêcher les écoutes clandestines de paquets et les accès non autorisés par des intrus. Cette technologie est conçue pour protéger les connexions importantes contre les attaques d’intrus.

Fondamentalement, leurs organisations utilisent un navigateur intégré. Dans certains cas - Mozilla Firefox.

Activer ou désactiver un protocole

Il est parfois impossible d'accéder à certains sites car le support des technologies SSL et TLS est désactivé. Une notification apparaît dans le navigateur. Alors, comment pouvez-vous activer les protocoles pour pouvoir continuer à bénéficier de communications sécurisées ?
1.Ouvrez le Panneau de configuration via Démarrer. Une autre façon : ouvrez l'Explorateur et cliquez sur l'icône d'engrenage dans le coin supérieur droit.

2. Accédez à la section « Options du navigateur » et ouvrez le bloc « Avancé ».

3.Cochez les cases à côté de « Utiliser TLS 1.1 et TLS 1.2 ».

4.Cliquez sur OK pour enregistrer vos modifications. Si vous souhaitez désactiver les protocoles, ce qui est fortement déconseillé, notamment si vous utilisez la banque en ligne, décochez les mêmes rubriques.

Quelle est la différence entre 1.0 et 1.1 et 1.2 ? 1.1 n’est qu’une version légèrement améliorée de TLS 1.0, qui hérite en partie de ses défauts. 1.2 est la version la plus sécurisée du protocole. En revanche, tous les sites ne peuvent pas s'ouvrir avec cette version du protocole activée.

Comme vous le savez, Skype Messenger est directement connecté à Internet Explorer en tant que composant Windows. Si vous n'avez pas coché le protocole TLS dans les paramètres, des problèmes peuvent survenir avec Skype. Le programme ne pourra tout simplement pas se connecter au serveur.

Si la prise en charge de TLS est désactivée dans les paramètres d'Internet Explorer, toutes les fonctions du programme liées au réseau ne fonctionneront pas. De plus, la sécurité de vos données dépend de cette technologie. Ne le négligez pas si vous effectuez des transactions financières dans ce navigateur (achats dans des boutiques en ligne, transfert d'argent via la banque en ligne ou le portefeuille électronique, etc.).

 

Il pourrait être utile de lire :

• Comment activer la confirmation d'échange sur Steam;
• aperçu complet des possibilités;
• Codes nuls pour VK Comment mettre un symbole transparent;
• Programmation en langage assembleur pour les débutants et plus Pourquoi le langage assembleur est nécessaire;
• Voitures : rapides comme l'éclair v1;
• Yandex a révélé les secrets du classement;
• Comment enregistrer une connexion. Identifiants et mots de passe. Comment trouver un identifiant;
• La signification des statuts des colis Arrivé au centre de tri du pays de destination;