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 le plus en évidence utilisé 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 les e-mails et une foule d’autres protocoles.

TLS est précieux car il garantit que l’autre partie à une connexion est bien qui il se dit, montre si les données conservent leur intégrité initiale et assure la confidentialité grâce au chiffrement.

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

Que fait TLS?

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

• Comment pouvons-nous savoir si la personne avec qui nous communiquons est bien qui elle se dit?
• Comment savoir que les données n’ont pas été falsifiées depuis leur envoi?
• Comment pouvons-nous empêcher d’autres personnes de voir et d’accéder aux données?

Ces problèmes sont cruciaux, en particulier 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 de authentifier l’autre partie dans une connexion, vérifier l’intégrité des données et fournir une protection cryptée.

Simplifions les choses et prétendons que vous essayez de transférer des informations dans les deux sens avec un ami qui vit à travers le pays. Si les informations sont sensibles, vous serez très inquiet des trois problèmes majeurs mentionnés ci-dessus.

Vous ne pouvez pas simplement envoyer une lettre et espérer pour le mieux, 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 permet de vérifier que votre destinataire est légitime, un moyen de vérifier si les messages ont été modifiés et un moyen de les protéger des regards indiscrets.

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

Pour revenir à notre analogie avec les lettres, la partie authentification de TLS serait un peu comme envoyer une lettre via un service de messagerie nécessitant une identification. Lorsque le courrier remet la lettre, il compare l’identité de la personne à son visage et vérifie si le destinataire est la bonne personne..

La phase d’établissement des clés 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 service de messagerie aura vérifié l’identité et que le numéro d’identification 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 en toute sécurité des informations avec le protocole d’application. Pour continuer notre analogie, transmettre des données en toute sécurité 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 serait en mesure de le dire par la signature déchirée (cela se fait en fait avec les mathématiques, mais encore une fois, nous le couvrirons en profondeur plus tard).

Vous mettriez alors la lettre dans une petite boîte en métal qui avait une serrure à combinaison, définissant la combinaison comme le numéro de broche que vous avez établi conjointement avec votre destinataire. Vous enverriez la boîte par le courrier qui vérifie l’identification lors de la livraison des colis. Votre destinataire répondrait de la même manière et toute communication future suivrait les mêmes étapes.

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

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 est juste pour vous donner une visualisation de ce qui se passe et le raisonnement derrière cela. Dans les sections suivantes, nous couvrirons ce qui se passe réellement en détail.

TLS contre SSL

En lisant sur TLS, vous verrez souvent la mention de SSL ou même comme TLS / SSL. Secure Sockets Layer (SSL) est l’ancienne version de TLS, mais beaucoup dans l’industrie se réfèrent toujours à TLS sous l’ancien surnom. Cet article utilisera le terme TLS partout, 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 entreprise 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, cependant, il contenait encore un certain nombre de défauts graves. SSL 3.0 était une version fortement repensée et est sortie en 1996, avec de nombreux problèmes de sécurité résolus.

En 1996, l’IETF a publié un projet de SSL 3.0 dans RFC 6101. L’IETF a formé un groupe de travail pour normaliser SSL, publiant les résultats en 1999 sous le nom de TLS 1.0. Il a été documenté dans la RFC 2246 et la normalisation a inclus quelques modifications au protocole d’origine, ainsi que le changement de nom. Ces modifications sont le résultat de négociations entre Netscape, Microsoft et le groupe de travail IETF.

En 2006, l’IETF a publié la RFC 4346, 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 est sortie seulement deux ans plus tard en 2008. Elle comprenait la prise en charge des chiffrements de chiffrement authentifiés, un certain nombre de changements dans l’utilisation des fonctions de hachage et de nombreuses autres améliorations.

La prochaine version n’est arrivée qu’en 2023, lorsque TLS 1.3 a été défini. Il propose une multitude de changements, y compris le secret avancé, la suppression de la prise en charge d’algorithmes plus faibles et bien plus encore.

TLS 1.0 et 1.1 devraient désormais être obsolètes en 2023, mais la version 1.2 est largement utilisée. La version 1.3 commence à voir l’adoption accrue.

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 protocoles TLS par Jeffreytedjosukmono. Sous licence CC0.

Le protocole d’enregistrement contient cinq sous-protocoles distincts, chacun étant formaté comme 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 des parties dans une connexion pour informer l’autre s’il y a des erreurs, des problèmes de stabilité ou un compromis potentiel.
• Modifier la spécification de chiffrement – Ce protocole est utilisé par le client ou le serveur pour modifier les paramètres de chiffrement. C’est assez simple, donc nous ne le couvrirons 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 un élément central de TLS, nous allons donc le sauter 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 ils 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

C’est là 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’eux est traité plus loin dans l’article si vous devez vous y référer.

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

La poignée de main TLS de base

Diagramme montrant le processus de prise de contact TLS. Poignée de main TLS 1.2 complète par FleshGrinder. Sous licence CC0.

Dans ce type de prise de contact, seul le serveur est authentifié et non le client. Cela commence par la phase de négociation, où un client envoie un Bonjour client 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 de la prise en charge de la compression, un nombre aléatoire et d’autres informations

Le message Bonjour client est rencontré avec un 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é dans la liste du client. Il comprend également un nombre aléatoire différent.

Cela dépend de la suite de chiffrement qui a été sélectionnée, mais le serveur suivra généralement cela en envoyant un Certificat message d’authentification. Cela valide son identité et contient sa clé publique.

Si des échanges de clés éphémères Diffie-Hellman ou anonymes Diffie-Hellman sont utilisés, ceci est suivi d’un Échange de clés de serveur message. D’autres méthodes d’échange de clés ignorent cette partie. Lorsque le serveur a terminé avec son côté de la négociation, il envoie un Serveur Hello Done message.

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

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

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

Le client fait ensuite un suivi 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 la spécification de chiffrement message, ainsi qu’un Fini message avec le même contenu que ci-dessus. Le client essaie ensuite également de décrypter et de vérifier le contenu. Si tout est terminé avec succès, la prise de contact est terminée. À ce stade, le protocole d’application est établi. Les données peuvent ensuite être échangées en toute sécurité de la même manière que 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’après l’envoi du serveur 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és client comme dans la prise de contact TLS de base. Vient ensuite le Vérification du certificat message, qui comprend la signature numérique du client. Étant donné qu’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 le même principe que la prise de contact 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 couper une grande partie du processus en utilisant une poignée de main abrégée à la place. 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 qui a été 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 de calcul, cela permet de gagner du temps et de faciliter la connexion..

Le processus commence par la Bonjour client message. Il ressemble beaucoup au message Client Hello précédent, mais il contient également 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, le Certificat et Échange de clés les étapes peuvent être sautées. le Modifier la spécification de chiffrement et Fini les messages sont envoyés de la même manière que la prise de contact TLS de base illustré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 des ID de session. Le serveur crypte les données de 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échiffre pour révéler les paramètres.

Les tickets de session ne sont pas utilisés aussi souvent, car ils nécessitent l’extension. 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

Les trois étapes les plus importantes de la prise de contact comprennent:

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

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

Les paramètres

Au début de la prise de contact, le client et le serveur négocient les paramètres de la connexion d’un commun accord. Le premier 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, qui a tendance à être la plus sécurisée.

Les parties décident également de l’algorithme d’échange de clés qu’elles utiliseront pour établir la clé principale. La fonction de hachage, l’algorithme de chiffrement et la méthode de compression sont également convenus à ce stade. Celles-ci seront traitées en détail lorsque nous discuterons de la 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 de nombreux autres mécanismes de sécurité, cela est réalisé avec ce qu’on appelle des certificats numériques.

Les certificats numériques sont des documents électroniques qui montrent le lien entre un individu ou une entité et leur clé publique. Ce lien est validé par une autorité de certification (CA), qui est une organisation approuvée qui vérifie que les deux sont réellement liées, 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 possède un certificat fiable et valide, 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) est une partie importante de la cryptographie, et il est largement utilisé dans les différents aspects de TLS. Voici une introduction rapide pour ceux qui ne connaissent pas son fonctionnement.

La courte explication est que la cryptographie à clé publique utilise une paire de clés pour le chiffrement et le déchiffrement, plutôt qu’une simple 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 sûr, la clé publique peut être partagée publiquement tandis que la clé privée doit être gardée secrète.

Le chiffrement à 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 pas eu l’occasion d’échanger des clés au préalable. Il le fait grâce à certaines propriétés uniques des nombres premiers. Vous pouvez en savoir plus dans notre article sur le cryptage à clé publique.

Établir un maître secret

Comme nous l’avons vu ci-dessus lorsque nous avons discuté du processus de la négociation TLS de base, après qu’une partie (ou les deux parties) prouve son identité avec son certificat public, l’étape suivante consiste à établir le secret principal, également connu sous le nom de secret partagé. Le secret principal est la base pour dériver les clés utilisées à la fois pour crypter et vérifier l’intégrité des données transmises entre les deux parties.

La prise de contact TLS peut utiliser un certain nombre de mécanismes différents pour partager ce secret en toute sécurité. Il s’agit notamment de RSA, de plusieurs types différents d’échange de clés Diffie-Hellman, PSK, Kerberos et autres. Chacun a ses propres avantages et inconvénients, tels que la confidentialité du transfert, mais ces différences sont hors de la portée 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émaster est dérivé selon la méthode d’échange de clés précédemment sélectionnée. Le client crypte le secret prémaster avec la clé publique du serveur pour l’envoyer en toute sécurité via la connexion.

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

• Clé MAC d’écriture client – Cette clé est utilisée par le serveur pour vérifier l’intégrité des 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 vérifier l’intégrité des données envoyées par le serveur.
• Clé de chiffrement d’écriture client – Le serveur utilise cette clé pour crypter les données envoyées par le client.
• Clé de chiffrement d’écriture du serveur – Le client utilise cette clé pour crypter les données envoyées par le serveur.
• Clé IV d’écriture client – La clé IV d’écriture client est utilisée par le serveur dans les chiffrements AEAD, mais pas lorsque d’autres algorithmes d’échange de clés sont utilisés.
• Clé IV d’écriture du serveur – De même, cette clé est utilisée par le client dans les chiffrements AEAD, mais pas lorsque d’autres algorithmes d’échange de clés sont utilisés.

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 qui peuvent être utilisées à la fois pour l’authentification et le chiffrement. Des clés distinctes sont utilisées par précaution pour les deux processus.

Une fois que les clés d’authentification et de cryptage ont été 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 l’établissement de liaison 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 pour s’adapter à 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 renvoient toujours le même résultat chaque fois qu’elles reçoivent la même entrée.

L’expéditeur signe ces données avec leur clé privée pour former ce qu’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é altéré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.

S’ils 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 ont é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 le cryptage, le salage et le hachage.

Algorithmes de chiffrement

TLS utilise un cryptage à clé symétrique pour assurer la confidentialité des données qu’il transmet. Contrairement au cryptage à clé publique, une seule clé est utilisée à la fois dans les processus de cryptage et de décryptage. Une fois que les données ont été crypté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 de codage 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, en particulier depuis l’attaque CRIME (voir le Problèmes de sécurité TLS section ci-dessous) s’est avéré capable de tirer parti des données compressées pour le détournement 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 commun qui est utilisé pour empêcher que des indices dans la structure des données chiffré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 qu’une erreur grave s’est produite, le protocole d’alerte permet à l’expéditeur d’informer l’autre partie. Ces messages ont deux types, soit d’avertissement, soit fatals. Un message d’avertissement indique que la session est instable et permet au destinataire de déterminer si la session doit être poursuivie ou non.

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 choses comme l’échec du déchiffrement, une autorité de certification inconnue, un paramètre illégal et bien plus encore.

TLS & le modèle OSI

Le modèle OSI est un moyen de conceptualiser et de normaliser 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 a sept couches distinctes qui montrent les niveaux auxquels les protocoles fonctionnent, cependant, TLS ne rentre pas dans un seul. Il circule sur un autre protocole de transport comme TCP, ce qui devrait impliquer qu’il est au-dessus de la quatrième couche, la couche de transport. Il est surtout utilisé comme une 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 voir, TLS n’est tout simplement pas conforme au modèle OSI. Cela ne signifie pas que TLS est défectueux ou erroné, mais montre simplement que le modèle OSI est défectueux et ne peut pas prendre en compte tous nos protocoles de communication.

Utilisation de TLS

TLS est utilisé pour sécuriser une proportion importante de nos communications en ligne. Normalement, il est implémenté sur des protocoles comme le Protocole de contrôle de transmission (TCP), mais il peut également être utilisé dans le protocole DCCP (Datagram Congestion Control Protocol) et le protocole 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 protocole HTTPS (Hypertext Transfer Protocol Secure), 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 verrouillage verte 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 chiffrement et d’authentification pour former un tunnel qui peut connecter des hôtes et des réseaux entre eux. Les technologies VPN basées sur TLS comme OpenVPN sont avantageuses par rapport à des alternatives comme IPsec, car OpenVPN n’est pas connu pour avoir de graves problèmes de sécurité. Ces VPN peuvent également être plus faciles à configurer.

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

Problèmes de sécurité TLS

Comme la plupart des protocoles, TLS a connu un certain nombre de vulnérabilités et d’attaques théoriques antérieures contre ses diverses implémentations. Malgré cela, les dernières versions sont considérées comme sécurisées à des fins pratiques.

Les versions antérieures, telles que SSL 2.0 et 3.0 (et TLS 1.0, qui est essentiellement le même que SSL 3.0) comportent de nombreuses failles de sécurité, mais comme ce sont des 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 nouvelles versions de TLS ont de nombreuses mises à niveau qui le rendent moins vulnérable que SSL. Malgré cela, le protocole a toujours rencontré les problèmes de sécurité suivants:

Attaques de renégociation

L’une des caractéristiques de TLS est qu’il permet aux paires de clients et de serveurs de renégocier les paramètres de leur connexion existante. En 2009, il a été découvert que cela pourrait être exploité par des attaquants afin qu’ils puissent injecter du trafic afin de donner l’impression qu’il provient du client. Les serveurs accepteront la demande comme légitime, ce qui signifie que les attaquants pourraient potentiellement manipuler les messages sortants.

Cette attaque ne permet pas à l’attaquant de voir la réponse, mais elle a toujours le potentiel d’être dommageable. Une extension qui empêchera ces attaques est actuellement une norme proposée.

BÊTE

L’attaque Exploiter le navigateur contre 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 des blocs de chiffrement dans TLS, qui peut être utilisée pour déchiffrer les messages. Cette attaque affecte uniquement TLS 1.0, qui est une version ancienne et plus faible du protocole. Bien qu’il ne soit pas obsolète avant 2023, les utilisateurs devraient plutôt utiliser les versions 1.2 et 1.3.

Attaques temporelles

Ces attaques par canal latéral analysent le temps nécessaire à l’exécution d’un algorithme, puis utilisent ces informations pour travailler en arrière et déterminer la clé. En 2013, l’attaque Lucky Thirteen a été découverte pour tirer parti à la fois d’une attaque de synchronisation et d’une attaque oracle de remplissage pendant la vérification du code d’authentification de message (MAC). Cette attaque peut être utilisée pour casser l’algorithme TLS, bien qu’elle ne soit pas considérée comme dangereuse pour la majorité des utilisateurs TLS.

LA CRIMINALITÉ & VIOLATION

L’attaque CRIME fonctionne contre une gamme de protocoles. Lorsque les données ont été compressées, elles peuvent générer du contenu à partir de 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 préoccupante lorsque la compression HTTP est utilisée, car il n’existe pas de stratégies d’atténuation efficaces.

En 2013, il a été constaté que l’exploit de reconnaissance et d’exfiltration du navigateur via la compression adaptative d’hypertexte (BREACH) affectait la compression HTTP de manière similaire. Cette version de l’attaque peut récupérer des adresses e-mail et d’autres données précieuses qui ont été 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 déclassement

Ce sont des 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 en est un bon exemple car elle pourrait faire en sorte que les serveurs vulnérables utilisent 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 un accès complet à la session.

Heartbleed

Heartbleed était une faille de sécurité qui a été accidentellement introduite dans la bibliothèque de cryptographie OpenSSL en 2012, mais pas rendu public avant 2014. Comme il s’agit d’une implémentation de TLS si couramment utilisée, elle a causé des dommages mondiaux importants.

L’un des développeurs de l’extension TLS Heartbeat a ajouté une vulnérabilité de sur-lecture du tampon, qui permet d’exposer des données supplémentaires. L’erreur n’a pas été détectée lors de la révision du code, ce qui a entraîné un certain nombre d’attaques importantes.

Étant donné que la bibliothèque OpenSSL est implémentée si largement, le coût international d’atténuation du problème a fini par être assez cher. Les administrateurs de serveur ont dû installer le nouveau correctif et régénérer les certificats et les paires de clés qui pourraient avoir été compromis pendant la période de deux ans où la vulnérabilité existait.

NOYER

L’attaque de décryptage RSA avec obsolète et affaiblissement du cryptage électronique (DROWN) a été annoncée en 2016 et tire parti de la prise en charge du serveur pour SSL 2.0. Il utilise une attaque de texte chiffré 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 qui prend en charge SSL 2.0..

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

L’attaque peut être atténuée en ne partageant pas les certificats de 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é trouvée en 2016. Elle exploite les faiblesses du protocole WPAD (Web Proxy Autodiscovery Protocol). 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 une forme d’authentification, l’attaque Unholy PAC permet à un attaquant de reprendre le compte d’un utilisateur.

Le 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 assez mineurs et peuvent ou ont été atténués. À mesure que la technologie progresse, des vulnérabilités sont découvertes et de nouvelles attaques sont développées, TLS continuera d’avoir plus de problèmes de sécurité. Malgré cela, pour l’instant et dans un avenir prévisible, il semble que TLS sera toujours l’un des outils principaux et les plus fiables que nous utilisons pour sécuriser notre monde en ligne.

Technologie d’entreprise de cybersécurité par TheDigitalArtist sous licence CC0