Qu’est-ce que TLS et comment ça marche ?

Transport Layer Security (TLS) est l'un des protocoles de sécurité les plus importants et les plus utilisés. Il protège une proportion importante des données transmises en ligne. C'est surtoututilisé pour sécuriser les données qui transitent entre un navigateur Web et un site Web via HTTPS, mais il peut également être utilisé pour sécuriser le courrier électronique et de nombreux autres protocoles.

TLS est précieux car il garantit que l'autre partie dans une connexion est bien celle qu'elle prétend être, montre si les données conservent leur intégrité initiale et assure la confidentialité grâce au cryptage.

TLS utilise une gamme d'algorithmes et de schémas différents pour atteindre ces objectifs. Cela peut sembler compliqué, mais cet article abordera un aspect à la fois pour vous donner un aperçu approfondi du fonctionnement de TLS pour sécuriser les connexions.

Que fait TLS ?

Lors de l’envoi d’informations en ligne, nous sommes confrontés à trois problèmes de sécurité majeurs :

• Comment pouvons-nous savoir si la personne avec laquelle nous communiquons est réellement celle qu’elle prétend être ?
• Comment pouvons-nous savoir que les données n’ont pas été falsifiées depuis qu’ils les ont envoyées ?
• Comment pouvons-nous empêcher d’autres personnes de voir et d’accéder aux données ?

Ces questions sont cruciales, surtout lorsque nous envoyons des informations sensibles ou précieuses. TLS utilise une gamme de techniques cryptographiques pour résoudre chacun de ces trois problèmes. Ensemble, ils permettent au protocole deauthentifier l'autre partie dans une connexion, vérifier l'intégrité des données et assurer une protection cryptée.

Simplifions les choses et imaginons que vous essayez de transférer des informations avec un ami qui vit à l’autre bout du pays. Si les informations sont sensibles, vous serez très inquiet des trois problèmes majeurs évoqués ci-dessus.

Vous ne pouvez pas simplement envoyer une lettre et espérer le meilleur, surtout si vous pensez que vos communications seront ciblées par des attaquants. Au lieu de cela, vous avez besoin d'un système qui vous permette de vérifier que votre destinataire est légitime, d'un moyen de vérifier si les messages ont été modifiés et d'un moyen de le protéger des regards indiscrets.

TLS répond à ces exigences en utilisant un certain nombre de processus différents. Cela commence par ce qu'on appelle un Poignée de main TLS , où l'authentification a lieu et où les clés sont établies.

Pour revenir à notre analogie avec la lettre, la partie authentification de TLS serait un peu comme l'envoi d'une lettre via un coursier nécessitant une identification. Lorsque le coursier remettait la lettre, il comparait la pièce d’identité de la personne à son visage et vérifiait si le destinataire était la bonne personne ou non.

La phase d'établissement clé serait un peu comme si votre lettre contenait la moitié d'un code PIN que vous aviez l'intention d'utiliser dans de futures communications. Vous demanderiez à votre destinataire de fournir la seconde moitié du numéro et de vous l'envoyer dans sa lettre de retour.

Une fois que le coursier aura vérifié l'identité et que le numéro PIN aura été établi, vous disposerez de tout ce dont vous avez besoin pour envoyer des informations en toute sécurité. En réalité, ces étapes sont beaucoup plus complexes, mais nous y reviendrons plus tard.

TLS échange des informations en toute sécurité avec le protocole d'application. Pour poursuivre notre analogie, transmettre en toute sécurité des données via TLS reviendrait à écrire un message et à le mettre dans une enveloppe. Vous écririez votre signature sur le sceau, de sorte que si la lettre était falsifiée, votre destinataire puisse le savoir grâce à la signature déchirée (cela se fait en fait avec des mathématiques, mais encore une fois, nous y reviendrons en profondeur plus tard).

Vous placeriez ensuite la lettre dans une petite boîte métallique dotée d'une serrure à combinaison, définissant la combinaison comme le code PIN que vous avez établi conjointement avec votre destinataire. Vous enverriez la boîte par l'intermédiaire du coursier qui vérifie l'identification lors de la livraison des colis. Votre destinataire répondra de la même manière et toute communication future suivra les mêmes étapes.

TLS résout nos trois problèmes d'une manière relativement similaire. Le coursier sert à authentifier le destinataire et à s'assurer que la boîte est livrée à la personne prévue. La boîte verrouillée sert de forme de cryptage, empêchant toute personne autre que votre partenaire d'accéder aux lettres. L'enveloppe signée vous permet de savoir si le message a été falsifié.

Il s’agit d’une approximation très approximative de ce que fait TLS. En réalité,TLS a lieu entre les clients et les serveurs, plutôt que deux personnes qui s'envoient du courrier. L’analogie sert simplement à vous donner une visualisation de ce qui se passe et du raisonnement qui le sous-tend. Dans les sections suivantes, nous aborderons en détail ce qui se passe réellement.

TLS contre SSL

Lorsque vous lisez sur TLS, vous verrez souvent mention de SSL ou même de TLS/SSL. Couche de sockets sécurisée (SSL) est l'ancienne version de TLS, mais de nombreux acteurs du secteur font encore référence à TLS sous l'ancien surnom. Cet article utilisera le terme TLS tout au long, mais il est important de noter que les noms sont souvent utilisés de manière interchangeable. Vous pouvez en savoir plus sur SSL dans notre guide .

L'histoire de TLS

Tout a commencé avec la nécessité de sécuriser la couche transport. Comme nous l'avons mentionné ci-dessus, le précurseur de TLS était SSL. Les premières versions de SSL ont été développées dans les années 90 par Netscape, une société qui a construit l'un des premiers navigateurs Web.

SSL 1.0 n'a jamais été publié car il contenait de graves vulnérabilités.La version 2.0 est sortie avec Netscape Navigator 1.1 en 1995, mais il contenait encore un certain nombre de défauts sérieux. SSL 3.0 était une version fortement repensée et sortie en 1996, avec de nombreux problèmes de sécurité résolus.

En 1996,l'IETF a publié une ébauche de SSL 3.0 en RFC6101 . L'IETF a formé un groupe de travail pour normaliser SSL, publiant les résultats en 1999 sous le nom de TLS 1.0. Cela a été documenté dans RFC2246 et la normalisation comprenait certaines modifications du protocole original, ainsi qu'un changement de nom. Ces modifications sont le résultat de négociations entre Netscape, Microsoft et le groupe de travail de l'IETF.

En 2006, l'IETF a publié RFC4346 , qui documente TLS 1.1. Cette version contenait de nouvelles dispositions de sécurité et un certain nombre d'autres mises à jour. La version 1.2 a été publiée deux ans plus tard, en 2008. Elle incluait la prise en charge des chiffrements authentifiés, un certain nombre de modifications dans la façon dont les fonctions de hachage étaient utilisées et de nombreuses autres améliorations.

La prochaine version n'est arrivée qu'en 2018, lorsque TLS 1.3 a été défini. Il comporte une multitude de changements, notamment le secret transmis, la suppression de la prise en charge des algorithmes les plus faibles et bien plus encore.

En février 2021, TLS 1.3 était pris en charge par près de 43 % des principaux sites Web d'Alexa, selon une enquête de Qualys . La même source a montré que plus de 99 % des sites Web prennent en charge TLS 1.2. Les principaux navigateurs tels que Safari , Chrome et Edge, ont déjà cessé de prendre en charge TLS 1.0 et 1.1 par défaut. Microsoft Bord et Mozilla Firefox fera de même dans un avenir proche.

TLS : Les détails techniques

TLS se compose de nombreux éléments différents. La partie fondamentale est le protocole d’enregistrement, le protocole sous-jacent responsable de la structure globale de tout le reste.

Diagramme montrant la pile TLS. Pile de protocole TLS par Jeffreytedjosukmono. Autorisé sous CC0 .

Le protocole d'enregistrement contient cinq sous-protocoles distincts, chacun étant formaté comme suit : enregistrements :

• Poignée de main – Ce protocole est utilisé pour configurer les paramètres d’une connexion sécurisée.
• Application – Le protocole d'application commence après le processus de prise de contact et c'est là que les données sont transmises en toute sécurité entre les deux parties.
• Alerte – Le protocole d'alerte est utilisé par l'une ou l'autre des parties dans une connexion pour avertir l'autre en cas d'erreurs, de problèmes de stabilité ou de compromission potentielle.
• Modifier les spécifications de chiffrement – Ce protocole est utilisé soit par le client, soit par le serveur pour modifier les paramètres de chiffrement. C’est assez simple, nous ne l’aborderons donc pas en profondeur dans cet article.
• Battement de coeur – Il s'agit d'une extension TLS qui permet à un côté de la connexion de savoir si son homologue est toujours actif et empêche les pare-feu de fermer les connexions inactives. Ce n’est pas une partie essentielle de TLS, nous l’ignorerons donc dans ce guide.

Chacun de ces sous-protocoles est utilisé à différentes étapes pour communiquer différentes informations. Les plus importants à comprendre sont la poignée de main et les protocoles d'application, car ceux-ci sont responsables de l'établissement de la connexion puis de la transmission sécurisée des données.

Le protocole de prise de contact TLS 1.2

C'est ici que la connexion est établie de manière sécurisée. Cela peut sembler complexe si vous êtes nouveau dans certains concepts, mais chacun d'entre eux est abordé plus loin dans l'article si vous avez besoin de vous y référer.

Il existe trois types de base de négociation TLS : poignée de main TLS de base , le poignée de main TLS authentifiée par le client et le poignée de main abrégée .

La poignée de main de base TLS 1.2

Diagramme montrant le processus de prise de contact TLS. Prise de contact TLS 1.2 complète par FleshGrinder. Autorisé sous CC0 .

Dans ce type de handshake, seul le serveur est authentifié et non le client. Cela commence par la phase de négociation, où un client envoie un Client Bonjour message. Celui-ci contient la version la plus élevée de TLS prise en charge par le client, les suites de chiffrement possibles, une indication indiquant s'il prend en charge la compression, un nombre aléatoire et d'autres informations.

Le message Client Hello reçoit un message Serveur Bonjour message. Cette réponse contient l'ID de session, la version du protocole, la suite de chiffrement et la compression (le cas échéant) que le serveur a sélectionnés dans la liste des clients. Il comprend également un nombre aléatoire différent.

Cela dépend de la suite de chiffrement sélectionnée, mais le serveur suivra généralement celle-ci en envoyant un Certificat message pour l'authentification. Celui-ci valide son identité et contient sa clé publique.

Si des échanges de clés Diffie-Hellman éphémères ou anonymes sont utilisés, ceci est suivi d'un Échange de clés de serveur message. Les autres méthodes d'échange de clés ignorent cette partie. Lorsque le serveur a terminé sa partie de la négociation, il envoie un Serveur Bonjour Terminé message.

C’est maintenant au tour du client. En fonction de la suite de chiffrement choisie, il enverra un Échange de clé client message. Celui-ci peut contenir une clé publique ou un secret pré-maître, qui est chiffré avec la clé publique du serveur.

Les deux parties utilisent ensuite les nombres aléatoires et le secret préalable pour trouver un secret principal. Les clés sont dérivées du secret principal, qui sont ensuite utilisées pour authentifier et chiffrer les communications.

Le client envoie ensuite un Modifier les spécifications de chiffrement message. Cela indique au serveur que les messages suivants seront désormais authentifiés et chiffrés (même si parfois le chiffrement ne peut pas être utilisé).

Le client poursuit ensuite avec un Fini message, qui est crypté et contient également un code d'authentification de message (MAC) pour l'authentification. Le serveur déchiffre ce message et vérifie le MAC. Si l'un de ces processus échoue, la connexion doit être rejetée.

C'est maintenant au tour du serveur d'envoyer un Modifier les spécifications de chiffrement message, ainsi qu'un Fini message avec le même contenu que ci-dessus. Le client tente ensuite également de décrypter et de vérifier le contenu. Si tout cela se déroule avec succès, la poignée de main est terminée. À ce stade, le protocole de candidature est établi. Les données peuvent alors être échangées de manière sécurisée de la même manière que les Fini message d'en haut, avec authentification et cryptage optionnel.

Prise de contact TLS authentifiée par le client

Cette prise de contact ressemble beaucoup à la prise de contact TLS de base, mais le client est également authentifié. La principale différence est qu'une fois que le serveur a envoyé son Certificat message, il envoie également un Demande de certificat message demandant le certificat du client. Une fois le serveur terminé, le client envoie son certificat dans un Certificat message.

Le client envoie ensuite son Échange de clé client message, tout comme dans la poignée de main TLS de base. Ceci est suivi par le Vérification du certificat message, qui comprend la signature numérique du client. Puisqu’elle est calculée à partir de la clé privée du client, le serveur peut vérifier la signature à l’aide de la clé publique envoyée dans le cadre du certificat numérique du client. Le reste de la Prise de contact TLS authentifiée par le client suit les mêmes lignes que la poignée de main TLS de base.

Poignée de main TLS abrégée

Une fois qu'une poignée de main a déjà eu lieu, TLS permet de supprimer une grande partie du processus en utilisant à la place une poignée de main abrégée. Ces poignées de main utilisent l'ID de session pour lier la nouvelle connexion aux paramètres précédents.

Une poignée de main abrégée permet aux deux parties de reprendre la connexion sécurisée avec la même configuration que celle négociée précédemment. Étant donné qu'une partie de la cryptographie normalement impliquée dans le lancement d'une poignée de main peut être assez lourde en ressources informatiques, cela permet de gagner du temps et de faciliter la connexion.

Le processus commence par le Client Bonjour message. Cela ressemble beaucoup au message Client Hello précédent, mais il contient également le ID de session de la connexion précédente. Si le serveur connaît l'ID de session, il l'inclut dans son Serveur Bonjour message. S'il ne reconnaît pas l'ID de session, il renverra un numéro différent et une négociation TLS complète devra avoir lieu à la place.

Si le serveur reconnaît l'ID de session, alors le Certificat et Échange de clés des étapes peuvent être sautées. Le Modifier les spécifications de chiffrement et Fini les messages sont envoyés de la même manière que la poignée de main TLS de base présentée ci-dessus. Une fois que le client a déchiffré le message et vérifié le MAC, les données peuvent être envoyées via la connexion TLS sécurisée.

Il existe également une extension TLS qui permet de reprendre les connexions avec des tickets de session au lieu d'ID de session. Le serveur crypte les données sur la session et les envoie au client. Lorsque le client souhaite reprendre cette connexion, il envoie le ticket de session au serveur qui le décrypte pour en révéler les paramètres.

Les tickets de session ne sont pas utilisés aussi fréquemment, car ils nécessitent une prolongation. Malgré cela, ils peuvent être avantageux dans certaines situations, car le serveur n’a rien à stocker.

Déballage de la poignée de main TLS 1.2

Les trois étapes les plus importantes de la poignée de main sont les suivantes :

• les paramètres sont sélectionnés,
• il effectue l'authentification, et
• les clés sont établies.

Examinons-les un peu plus en détail afin que vous puissiez comprendre ce qui se passe réellement.

Les paramètres

Au début du handshake, le client et le serveur négocient les paramètres de la connexion d’un commun accord. Le premier d’entre eux est la version de TLS qui sera utilisée. Il s’agit de la version la plus élevée prise en charge par les deux parties, et qui tend à être la plus sécurisée.

Les parties décident également quel algorithme d'échange de clés elles utiliseront pour établir la clé principale. La fonction de hachage, l'algorithme de cryptage et la méthode de compression sont également convenus à cette étape. Ceux-ci seront abordés en détail lorsque nous discuterons de Protocole d'application plus loin dans l'article.

Authentification : certificats numériques

L'authentification est un élément clé de la sécurisation d'un canal de communication, car elle permet aux deux parties de savoir qu'elles parlent réellement à qui elles pensent être et non à un imposteur. Dans TLS et dans de nombreux autres mécanismes de sécurité, cela est réalisé grâce à ce que l'on appelle les certificats numériques.

Les certificats numériques sont des documents électroniques qui montrent le lien entre un individu ou une entité et sa clé publique. Ce lien est validé par une autorité de certification (CA), qui est une organisation de confiance qui vérifie que les deux sont réellement liés, puis utilise sa propre réputation pour accorder la confiance au certificat.

Différents niveaux de certificat représentent différents degrés de confiance. La chose importante à savoir est que si un client ou un serveur dispose d’un certificat fiable et valide, alors il est raisonnable de supposer que la clé publique est légitime et que vous n’avez pas affaire à un attaquant.

Une note sur les clés publiques

Le chiffrement à clé publique (également appelé chiffrement asymétrique) constitue une partie importante de la cryptographie et est largement utilisé dans les différents aspects de TLS. Voici une introduction rapide pour ceux qui ne connaissent pas son fonctionnement.

La brève explication est que cryptographie à clé publique utilise une paire de clés pour le cryptage et le déchiffrement, plutôt qu'une seule clé. L’expéditeur utilise la clé publique de son destinataire pour crypter les données. Une fois chiffré, il ne peut être déchiffré que par la clé privée correspondante du destinataire. Bien entendu, la clé publique peut être partagée publiquement tandis que la clé privée doit être gardée secrète.

Le cryptage à clé publique permet aux parties de partager des informations en toute sécurité, même si elles ne se sont jamais rencontrées ou n'ont jamais eu l'occasion d'échanger des clés au préalable. Cela se fait grâce à certaines propriétés uniques des nombres premiers.

Établir un secret principal

Comme nous l'avons vu ci-dessus lorsque nous avons discuté du processus de prise de contact TLS de base, après qu'une partie (ou les deux parties) ait prouvé son identité avec son certificat public,l'étape suivante consiste à établir le secret principal, également appelé secret partagé. Le secret principal est la base sur laquelle dériver les clés utilisées à la fois pour chiffrer et vérifier l'intégrité des données transmises entre les deux parties.

La négociation TLS peut utiliser un certain nombre de mécanismes différents pour partager ce secret en toute sécurité. Ceux-ci inclus RSA , plusieurs types différents de Échange de clés Diffie-Hellman , PSK, Kerberos et autres. Chacun a ses propres avantages et inconvénients, comme le fait de garantir le secret ultérieur, mais ces différences sortent du cadre de cet article.

Le processus exact dépendra de la méthode d'échange de clés choisie, mais il suit les étapes approximatives mentionnées dans La poignée de main TLS de base section.

Le secret pré-maître est dérivé selon la méthode d'échange de clé précédemment sélectionnée. Le client chiffre le secret pré-maître avec la clé publique du serveur pour l'envoyer en toute sécurité via la connexion.

Le client et le serveur utilisent ensuite tous deux le secret pré-maître et les nombres aléatoires qu'ils ont envoyés au début de la communication pour trouver le secret principal. Une fois la clé principale calculée, elle est utilisée pour créer quatre ou six clés distinctes. Voici les:

• Le client écrit la clé MAC – Cette clé est utilisée par le serveur pour authentifier les données envoyées par le client.
• Clé MAC d'écriture du serveur – La clé MAC d'écriture du serveur est utilisée par le client pour authentifier les données envoyées par le serveur.
• Clé de chiffrement d'écriture client – Cette clé crypte les données écrites par le client.
• Clé de chiffrement d'écriture du serveur – La clé de chiffrement d'écriture du serveur chiffre les données écrites par le serveur.
• Clé IV d'écriture du client – La clé IV d'écriture client est générée lorsque AEAD est utilisé pour le chiffrement et l'authentification.
• Clé IV d'écriture du serveur – De même, la clé IV d'écriture du serveur est générée lorsque AEAD est utilisé pour le cryptage et l'authentification.

L'établissement de la clé principale est une partie importante de la négociation TLS, car elle permet aux deux côtés de la connexion de dériver en toute sécurité des clés pouvant être utilisées à la fois pour l'authentification et le chiffrement. Des clés distinctes sont utilisées pour les deux processus par mesure de précaution.

Une fois les clés d'authentification et de chiffrement dérivées, elles sont utilisées pour protéger à la fois Fini messages, ainsi que les enregistrements envoyés via le protocole d'application.

Le protocole d'application

Une fois qu'une connexion sécurisée a été établie par la poignée de main TLS, le protocole d'application est utilisé pour protéger les données transmises. Il peut être configuré pour utiliser une large gamme d’algorithmes adaptés à différents scénarios.

Algorithmes d'authentification

L'intégrité des messages peut être vérifiée avec de nombreux algorithmes différents. Ceux-ci inclus:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Pour prouver l'intégrité des données envoyées, l'expéditeur exécute les informations via une fonction de hachage pour renvoyer une chaîne de caractères unique. Ce sont des formules spéciales qui renverront toujours le même résultat chaque fois qu'elles recevront la même entrée.

L'expéditeur signe ces données avec sa clé privée pour former ce que l'on appelle une signature numérique. La signature numérique est ensuite jointe au message et envoyée au destinataire. Pour vérifier si les données conservent leur intégrité et n’ont pas été falsifiées,le destinataire déchiffre le hachage avec la clé publique de l'expéditeur. Ils utilisent ensuite la même fonction de hachage sur les données envoyées. Le destinataire compare ensuite les deux valeurs.

Si elles sont identiques, cela signifie que les données n'ont pas été modifiées depuis leur signature par l'expéditeur. S'ils sont différents, il est probable que les données aient été falsifiées ou qu'il y ait eu une autre erreur.

C’est la version courte de la façon dont les fonctions de hachage peuvent être utilisées pour montrer l’intégrité des données. Si vous souhaitez une compréhension plus approfondie, consultez notre article sur cryptage, salage et hachage .

Algorithmes de chiffrement

TLS utilise un cryptage à clé symétrique pour assurer la confidentialité des données qu'il transmet. Contrairement au chiffrement à clé publique, une seule clé est utilisée dans les processus de chiffrement et de déchiffrement. Une fois les données chiffrées avec un algorithme, elles apparaîtront comme un fouillis de texte chiffré. Tant qu’un algorithme approprié est utilisé, les attaquants ne pourront pas accéder aux données réelles, même s’ils les interceptent.

TLS peut utiliser de nombreux algorithmes différents, tels que Camellia ou ARIA, bien que le plus populaire soit AES .

Compression

La compression est le processus d'encodage des données pour qu'elles prennent moins de place. TLS prend en charge la compression si les deux côtés de la connexion décident de l'utiliser. Malgré cette capacité, il est généralement recommandé d'éviter d'utiliser TLS pour compresser les données, d'autant plus que l'attaque CRIME (voir la Problèmes de sécurité TLS ci-dessous) s'est avéré capable de tirer parti des données compressées pour le piratage de session.

Rembourrage

Le remplissage ajoute des données supplémentaires à un message avant qu'il ne soit chiffré. Il s’agit d’un processus cryptographique courant utilisé pour empêcher que des indices dans la structure des données cryptées ne révèlent leur véritable signification. TLS applique généralement le remplissage PKCS#7 aux enregistrements avant qu'ils ne soient chiffrés.

Protocole d'alerte

Si la connexion ou la sécurité devient instable, compromise ou si une erreur grave s'est produite,le protocole d'alerte permet à l'expéditeur de prévenir l'autre partie. Ces messages sont de deux types : avertissement ou fatal. Un message d'avertissement indique que la session est instable et permet au destinataire de déterminer si la session doit ou non être poursuivie.

Un message fatal indique au destinataire que la connexion a été compromise ou qu'une erreur grave s'est produite. L'expéditeur doit fermer la connexion après avoir envoyé le message. Le protocole d'alerte contient également des informations sur la cause du problème de connexion particulier. Cela peut inclure des éléments tels qu’un échec de décryptage, une autorité de certification inconnue, un paramètre illégal et bien plus encore.

Le protocole de prise de contact TLS 1.3

Presque tous les sites Web prennent en charge TLS 1.2, mais près de la moitié prennent également en charge TLS 1.3 (à partir de février 2021) et leur nombre augmente rapidement. Alors que nous nous dirigeons vers la domination de TLS 1.3, il est également important de comprendre comment fonctionne la nouvelle version.

TLS 1.3 présente une série de changements importants, dont beaucoup ont un impact sur la poignée de main. Ces modifications ont principalement été apportées pour renforcer la sécurité du protocole et améliorer son efficacité. Nous passerons ici en revue les changements les plus importants, mais si vous souhaitez vraiment entrer dans les détails, vous devriez vous rendre sur notre site Web. Article expliqué sur les poignées de main TLS (SSL) .

Moins d'étapes

L’un des changements les plus importants apportés à TLS 1.3 est qu’il élimine certains messages de la poignée de main, ce qui la rend plus rapide. Dans TLS 1.2, le client et le serveur échangent chacun leurs messages Hello, et ce n'est qu'après cela qu'ils échangent leurs clés.

Dans TLS 1.3, le message Client Hello suppose que le serveur acceptera ses paramètres d'échange de clés préférés et lui envoie les données pertinentes . Lorsque le serveur prend en charge ces paramètres, il les utilise dans le cadre de son message Server Hello.

Non seulement cela peut éliminer les messages d’échange de clés, mais cela signifie que certaines données sont déjà chiffrées dans le cadre du message Server Hello. Cela améliore la sécurité. Dans les cas où le serveur ne prend pas en charge les préférences du client, il envoie simplement au client une demande de réessai Hello et les deux parties tentent d'établir une connexion en utilisant des paramètres différents.

Bien que ces demandes de nouvelle tentative Hello ajoutent des étapes supplémentaires lorsqu'elles sont nécessaires, Le mécanisme de TLS 1.3 finit par être plus rapide pour la majorité des connexions .

Moins de suites de chiffrement

Les anciennes versions de TLS offraient un grand nombre de suites de chiffrement permettant une mise en œuvre flexible. Cette gamme plus large de choix conduisait souvent à une mauvaise utilisation, ce qui entraînait une sécurité médiocre. En réponse, TLS 1.3 a réduit son offre à seulement cinq suites de chiffrement :

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Bien que les points ci-dessus ressemblent à une sorte de charabia technique, ce ne sont en réalité que des codes pour les chiffres. Par exemple, le premier point utilise un mode de chiffrement AEAD de AES-128 GCM , avec SHA-256 comme son HKDF. Les AEAD sont un type de chiffrement à clé symétrique, tandis que les HKDF sont des fonctions de dérivation de clé (KDF) basées sur des codes d'authentification de message basés sur le hachage (HMAC).

TLS et le modèle OSI

Le Modèle OSI est un moyen de conceptualiser et de standardiser la façon dont nous considérons nos différents systèmes et protocoles de communication. Il est important de noter qu’il ne s’agit que d’un modèle et que certains de nos protocoles ne s’y conforment pas.

L'OSI comporte sept couches distinctes qui montrent les niveaux auxquels les protocoles fonctionnent.TLS ne rentre dans aucun système.Il circule via un autre protocole de transport comme TCP, ce qui devrait impliquer qu'il se situe au-dessus de la quatrième couche, la couche de transport. Il est principalement utilisé comme couche de transport, mais comme il effectue des poignées de main, cela impliquerait qu'il fait partie des couches de présentation ou d'application.

Comme vous pouvez le constater, TLS n’est tout simplement pas conforme au modèle OSI. Cela ne signifie pas que TLS est défectueux ou erroné, cela montre simplement que le modèle OSI est défectueux et incapable de prendre en compte tous nos protocoles de communication.

Article similaire: Le modèle OSI

Utilisation de TLS

TLS est utilisé pour sécuriser une proportion importante de nos communications en ligne. Normalement, il est implémenté via des protocoles tels que leProtocole de contrôle de transmission (TCP), mais il peut également être utilisé dans le protocole DCCP (Datagram Congestion Control Protocol) et UDP (User Datagram Protocol).

Il peut sécuriser des protocoles comme HTTP, SMTP, FTP, XMPP et NNTP, ainsi que d'autres. L'application la plus courante est le Hypertext Transfer Protocol Secure (HTTPS), qui protège la connexion entre un navigateur Web et un site Web. Vous pouvez savoir quand HTTPS est utilisé pour sécuriser votre connexion en ligne, car une petite icône de cadenas vert apparaîtra à gauche de l'URL en haut de votre navigateur.

TLS peut également être utilisé pour créer des VPN, comme dans OpenConnect et OpenVPN. Il utilise ses capacités de cryptage et d’authentification pour former un tunnel capable de connecter les hôtes et les réseaux les uns aux autres. Les technologies VPN basées sur TLS comme OpenVPN sont avantageuses par rapport aux alternatives comme IPsec, car OpenVPN n'est pas connu pour avoir de sérieux problèmes de sécurité. Ces VPN peuvent également être plus faciles à configurer.

Une autre de ses utilisations est demessagerie sécurisée via STARTTLS. Lorsque TLS est implémenté, il empêche les attaquants d'accéder aux messages lorsqu'ils transitent entre les serveurs de messagerie.

Problèmes de sécurité TLS

Comme la plupart des protocoles, TLS a connu par le passé un certain nombre de vulnérabilités et d’attaques théoriques contre ses différentes implémentations. Malgré cela,les dernières versions sont considérées comme sécurisées pour des raisons pratiques.

Les versions précédentes, telles que SSL 2.0 et 3.0 (et TLS 1.0, qui est essentiellement le même que SSL 3.0) présentent de nombreuses failles de sécurité, mais comme il s'agit de protocoles anciens et obsolètes, nous n'entrerons pas dans les détails. Vous devriez plutôt utiliser TLS 1.2 et 1.3 pour sécuriser vos connexions.

Les versions les plus récentes de TLS comportent de nombreuses mises à niveau qui le rendent moins vulnérable que SSL. Malgré cela, le protocole présente toujours les problèmes de sécurité suivants :

Attaques de renégociation

L’une des fonctionnalités de TLS est qu’il permet aux paires client et serveur de renégocier les paramètres de leur connexion existante. En 2009, il a été découvert que cela pouvait être exploité par des attaquants afin d'injecter du trafic pour faire croire qu'il provenait du client. Les serveurs accepteront la demande comme légitime, ce qui signifie que des attaquants pourraient potentiellement manipuler les messages sortants.

Cette attaque ne permet pas à l’attaquant de voir la réponse, mais elle peut néanmoins être potentiellement dommageable. Une extension qui empêchera ces attaques est actuellement une norme proposée.

BÊTE

L'attaque Browser Exploit Against SSL/TLS (BEAST) a été découverte pour la première fois par des chercheurs en 2011. Elle tire parti de la vulnérabilité de chaînage de blocs de chiffrement dans TLS, qui peut être utilisée pour décrypter les messages. Cette attaque n’affecte que TLS 1.0, qui est une version ancienne et plus faible du protocole. Bien qu'il ne soit pas obsolète avant 2020, les utilisateurs devraient plutôt utiliser les versions 1.2 et 1.3.

Attaques chronométrées

Ces attaques par canal secondaire analysent le temps nécessaire à l'exécution d'un algorithme, puis utilisent ces informations pour travailler à rebours et déterminer la clé. En 2013, il a été découvert que l'attaque Lucky Thirteen exploitait à la fois une attaque temporelle et une attaque Oracle Padding pendant la vérification du code d'authentification du message (MAC). Cette attaque peut être utilisée pour casser l’algorithme TLS, même si elle n’est pas considérée comme dangereuse pour la majorité des utilisateurs de TLS.

CRIME ET INFRACTION

L’attaque CRIME fonctionne contre une série de protocoles. Lorsque les données ont été compressées, elles peuvent obtenir du contenu à partir des cookies d'authentification. Ces informations peuvent être utilisées pour le détournement de session. Bien qu’elle affecte un certain nombre de protocoles, l’attaque est particulièrement inquiétante lorsque la compression HTTP est utilisée, car il n’existe aucune stratégie d’atténuation efficace.

En 2013, il a été constaté que l’exploit BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) affectait la compression HTTP de la même manière. Cette version de l'attaque peut récupérer des adresses e-mail et d'autres données précieuses chiffrées avec TLS. L'attaque BREACH peut être atténuée en désactivant la compression HTTP ou en utilisant des techniques telles que la protection contre la falsification de requêtes intersites (CSRF).

Attaques de rétrogradation

Il s'agit d'attaques qui incitent les serveurs à utiliser des versions antérieures et moins sécurisées de TLS. Les attaquants pourraient utiliser ces techniques pour négocier l’utilisation d’échanges de clés et de chiffrements moins sécurisés. L'attaque Logjam est un bon exemple car elle pourrait obliger les serveurs vulnérables à utiliser Diffie-Hellman 512 bits, ce qui est faible. Les attaquants peuvent alors briser ce mécanisme d’échange de clés et extraire les clés, leur permettant ainsi un accès complet à la session.

Saignement de cœur

Heartbleed était une faille de sécurité introduite accidentellement dans la bibliothèque de cryptographie OpenSSL en 2012., mais n'a été rendu public qu'en 2014. Comme il s'agit d'une implémentation de TLS très couramment utilisée, elle a causé d'importants dégâts à l'échelle mondiale.

L'un des développeurs de l'extension TLS Heartbeat a ajouté une vulnérabilité de surcharge de tampon, qui permet d'exposer certaines données supplémentaires. L'erreur n'a pas été détectée lors de la révision du code, ce qui a conduit à un certain nombre d'attaques importantes.

Étant donné que la bibliothèque OpenSSL est si largement mise en œuvre, le coût international de l’atténuation du problème s’est avéré assez élevé. Les administrateurs de serveur ont dû installer le nouveau correctif et régénérer les certificats et les paires de clés qui auraient pu être compromis au cours des deux années d'existence de la vulnérabilité.

NOYER

L'attaque Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) a été annoncée en 2016 et profite de la prise en charge du serveur pour SSL 2.0. Il utilise une attaque par cryptogramme choisi contre les serveurs qui prennent toujours en charge SSL 2.0, ainsi que ceux qui partagent le même certificat de clé publique avec un autre serveur prenant en charge SSL 2.0.

Lorsque l'attaque a été annoncée, elle pouvait être lancée avec des coûts d'installation initiaux d'environ 18 000 dollars et environ 400 dollars pour chaque attaque distincte. Lorsque l'attaque DROWN réussit, elle acquiert les clés de session.

L'attaque peut être atténuée en ne partageant pas les certificats du serveur. Le groupe OpenSSL a également publié des correctifs qui suppriment la prise en charge des anciens protocoles et chiffrements, mais ceux-ci ne fonctionnent que si le certificat du serveur n'est pas partagé avec d'autres serveurs prenant en charge SSL 2.0.

PAC impie

Cette attaque a été découverte en 2016. Elle exploite les faiblesses découvertes dans le protocole de découverte automatique du proxy Web (WPAD). Lorsqu'un utilisateur tente de visiter un site Web via une connexion cryptée TLS, la faille peut rendre l'URL visible. Étant donné que les URL sont parfois envoyées aux utilisateurs comme forme d’authentification, l’attaque Unholy PAC permet à un attaquant de s’emparer du compte d’un utilisateur.

TLS est-il sûr ?

Bien qu'il puisse sembler qu'il existe de nombreux problèmes de sécurité, la réalité est que la plupart d'entre eux sont plutôt mineurs et peuvent ou ont été atténués. À mesure que la technologie progresse, que des vulnérabilités sont découvertes et que de nouvelles attaques sont développées, TLS continuera à rencontrer davantage de problèmes de sécurité. Malgré cela, pour l’instant et dans un avenir prévisible, il semble que TLS restera l’un des outils principaux et les plus fiables que nous utilisons pour sécuriser notre monde en ligne.

Technologie commerciale de cybersécurité par TheDigitalArtist sous licence CC0