TLS

Historique et versions

TLS est le successeur du protocole Secure Sockets Layer (SSL). Netscape a développé SSL en 1994 pour sécuriser son navigateur, Netscape Navigator. La dernière version de SSL était SSL 3.0. La première version de TLS, publiée en 1999, est basée sur SSL 3.0.

Les termes SSL et TLS sont souvent utilisés de manière interchangeable. En effet, la première version de TLS, 1.0, a été initialement développée en tant que version 3.1 de SSL. Cela signifie que, sauf indication contraire, ce qui est commercialisé aujourd'hui comme un certificat SSL utilise généralement le protocole TLS. Le terme SSL est toujours utilisé parce qu'il est plus familier. Le terme SSL/TLS est souvent utilisé pour décrire le protocole.

La dernière version de TLS est TLS 1.3, publiée en 2018 par l'Internet Engineering Task Force (IETF). L'IETF est une organisation internationale de normalisation chargée à l'origine d'orchestrer le développement du nouveau protocole.

SSL 3.0 a été officiellement mis au rancart en 2015. Cependant, TLS offre une compatibilité ascendante pour certains appareils plus anciens utilisant SSL.

Apple, Microsoft et Google cesseront de prendre en charge les versions TLS 1.0 et TLS 1.1 en 2020. Cela s'explique en partie par le fait que ces versions de TLS utilisent des technologies obsolètes, notamment des algorithmes tels que SHA-1 et MD5. Dans un premier temps, les sites web utilisant d'anciennes versions de TLS afficheront un message d'erreur. À terme, tous les accès aux sites web utilisant des versions TLS obsolètes seront bloqués.

La plupart des applications web actuelles utilisent TLS 1.2. L'adoption de TLS 1.3 devrait prendre du temps. Google estime que moins d'un pour cent des sites web utilisent TLS 1.0 ou 1.1. Il existe des solutions de contournement, par exemple l'extension LS_FALLBACK_SCSV, pour les applications anciennes qui ne sont pas compatibles avec la technologie TLS.

Fonctionnalité de TLS

TLS comporte trois fonctionnalités principales et une fonctionnalité de facto :

• Chiffrement - Il dissimule les données transférées entre deux parties, généralement un serveur client et une application web. Cela permet d'éviter les écoutes clandestines.
• Authentification - Certifie l'identité de deux parties communiquant sur l'internet. Cela permet d'éviter les attaques par usurpation d'identité.
• Intégrité - Vérifie que les données envoyées sur un réseau n'ont pas été altérées en cours de route. Cela permet d'éviter les attaques de type "man-in-the-middle". L'intégrité est garantie par l'utilisation d'un certificat délivré par une autorité de certification (AC) de confiance.
• Prévention de la relecture - Elle protège contre les attaques par force brute et les attaques de l'homme du milieu.

Où est-il utilisé ?

TLS est utilisé pour sécuriser les protocoles de la couche application comme FTP, HTTP et SMTP, par exemple. Ces protocoles fournissent la plupart des fonctions utilisées pour communiquer sur l'internet, comme l'envoi de courriels, le chat ou le téléchargement de données.

TLS permet l'authentification des identités numériques. Les cas d'utilisation typiques en entreprise comprennent l'authentification unique (SSO), la vérification des appareils dans un réseau IoT, les documents signés numériquement, le chiffrement des courriels pour protéger les informations commerciales sensibles et l'authentification de l'accès au réseau.

Pourquoi est-il utilisé ?

Le chiffrement TLS permet de protéger les applications internet contre les cyberattaques et les violations de données. Le protocole est la norme de connexion sécurisée pour la plupart des navigateurs populaires.

Google Chrome a récemment commencé à avertir les utilisateurs accédant à des pages HTTP que ces pages ne sont pas sécurisées. Les entreprises craignent que cela n'entraîne une perte de confiance de la part de leurs clients. C'est pourquoi Google, Apple et Microsoft encouragent l'utilisation d'au moins TLS 1.2.

TLS 1.0 et 1.1 sont vulnérables aux attaques CRIME, BEAST, FREAK, LogJam et POODLE, mais TLS 1.2 et TLS 1.3 offrent une protection renforcée lors des transferts de données. En outre, la norme de sécurité des données de l'industrie des cartes de paiement (PCI-DSS) exige au moins TLS 1.2 pour la conformité.

TLS 1.2 et 1.3 prennent en charge les suites de chiffrement et les algorithmes les plus récents, et ont supprimé les fonctions de hachage qui ne sont pas sûres, comme SHA-1 et MD5.

Comment cela fonctionne-t-il ?

Une poignée de main TLS initie une session TLS. IT n'est pas l'événement de la session sécurisée elle-même. La poignée de main TLS ne chiffre pas les données, mais elle détermine la méthode de chiffrement. Le cryptage des données a lieu au cours d'une session, à l'aide du secret partagé généré lors de la poignée de main TLS.

La poignée de main TLS commence par la négociation d'une version TLS et la sélection d'une suite de chiffrement appropriée. Une suite de chiffrement est une combinaison d'algorithmes. Chaque algorithme a une tâche, par exemple le chiffrement, l'authentification et l'échange de clés. Le serveur choisit d'emblée l'algorithme d'échange de clés qui sera utilisé.

La poignée de main utilise le chiffrement asymétrique pour initier une connexion. Cette méthode de cryptage entraîne une certaine surcharge en termes de ressources. Une clé publique est utilisée pour le cryptage et une clé privée pour le décryptage. Dans TLS, la paire de clés est utilisée pour créer une clé partagée, parfois appelée secret partagé, clé pré-maîtresse ou clé maîtresse. Une fois la poignée de main réussie, la session utilise la clé partagée, ou clé de session, pour chiffrer les données dans les messages ultérieurs entre le client et le serveur. La session utilise alors le chiffrement symétrique. Ce type de chiffrement est beaucoup moins coûteux que le chiffrement asymétrique et plus efficace.

Une poignée de main SSL/TLS se compose des messages et étapes suivants : ClientHello, ServerHello, Certificat (facultatif), ServerKeyExchange, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, ChangeCipherSpec, et Finished. Avant TLS 1.3, la poignée de main se déroule comme suit.

1. Le client envoie au serveur une liste de toutes les versions de TLS disponibles. La version préférée est la plus récente. Le client envoie également une liste des suites de chiffrement proposées. Le client génère un nombre aléatoire qui sera utilisé ultérieurement. Le client vérifie également s'il s'agit d'une session de reprise.
2. Le serveur confirme les options acceptables pour la connexion. Il génère également un nombre aléatoire qui sera utilisé ultérieurement.
3. Le serveur envoie un certificat numérique signé pour s'authentifier auprès du client. Sa clé publique est intégrée au certificat. Lors de la création d'une connexion TLS, le client vérifie que le certificat est valide et qu'il a été signé par une autorité de certification de confiance. Un certificat auto-signé ou non valide génère un message d'avertissement.
4. Le serveur envoie un message indiquant qu'il a terminé.
5. Le client crée une clé pré-maître et l'envoie au serveur. La clé pré-maître est cryptée avec la clé publique du serveur. Cette clé est extraite du certificat précédemment fourni par le serveur. Comme il s'agit d'un cryptage asymétrique, seul le serveur peut décrypter le message. Une fois que le serveur a reçu la clé pré-maître, il utilise sa clé privée pour la décrypter. Ce processus permet d'affirmer que les deux parties sont bien celles qu'elles prétendent être. Une fois que le serveur a reçu la clé pré-maîtresse, le serveur et le client calculent tous deux une clé maîtresse en utilisant les nombres aléatoires générés précédemment et la clé pré-maîtresse.
6. Le client envoie la clé maîtresse qu'il a calculée au serveur. Le client accepte d'utiliser la clé maîtresse à partir de maintenant. IT change la méthode de cryptage en symétrique.
7. Le client envoie un message indiquant qu'il a terminé.
8. Le serveur vérifie que sa clé principale calculée est la même que celle du client. Le serveur accepte d'utiliser la clé principale à partir de maintenant. IT change la méthode de chiffrement en méthode symétrique.
9. Le message final Finished du serveur est le premier message chiffré transmis à l'aide du secret partagé. Le secret partagé, qui est une clé de session, est également utilisé dans l'algorithme MAC (Message Authentication Code) pour vérifier qu'un message n'a pas été modifié.

Depuis TLS 1.3, le protocole est plus efficace. Le client détermine le meilleur protocole cryptographique pour la connexion et partage sa clé dans le premier message qu'il envoie au serveur. TLS 1.3 utilise le protocole Diffie-Hellman à courbe elliptique (ECDH). ECDH est un protocole d'accord de clé qui permet à un client et à un serveur de partager une clé secrète ou de créer une nouvelle clé secrète sur un canal qui n'est pas sécurisé.

Avantages de TLS 1.3

TLS 1.3 a été introduit pour réduire l'utilisation de technologies peu sûres comme les algorithmes obsolètes, permettre la rétrocompatibilité avec les anciennes versions du protocole, accélérer les connexions, améliorer la sécurité et utiliser des techniques plus récentes comme l'autorisation d'un nombre réduit d'options de chiffrement plus fiables.

TLS 1.3 a mis fin à la prise en charge de certains algorithmes et chiffrements obsolètes, comme l'algorithme DES, le chiffre RC4, le hachage SHA-1, le chiffre CBC, l'algorithme MD5, l'échange de clés RSA et certaines méthodes de chiffrement Diffie-Hellman (mais pas toutes). TLS 1.2 prend en charge 37 suites de chiffrement. TLS 1.3 ne prend en charge que cinq suites de chiffrement.

Traditionnellement, l'algorithme de chiffrement RSA était l'une des méthodes les plus populaires pour échanger des clés de session sécurisées. RSA a été quelque peu discrédité parce qu'il ne fournit pas de mode de clé éphémère (temporaire ou spécifique à la session), ce qui est nécessaire pour assurer une parfaite sécurité de transmission (Perfect Forward Secrecy - PFS). La PFS garantit que si un attaquant enregistre des informations chiffrées et parvient à voler la clé privée associée, il ne sera toujours pas en mesure de déchiffrer les informations.

Quatre nouvelles fonctionnalités de TLS 1.3 permettent d'accélérer la poignée de main TLS. La reprise de session TLS vérifie si un serveur et un client ont déjà communiqué, et si c'est le cas, certains contrôles de sécurité sont ignorés. Le faux départ TLS permet à un serveur et à un client de commencer à transmettre des données avant que la poignée de main TLS ne soit finalisée. La poignée de main TLS 1.3 ne nécessite qu'un seul aller-retour, au lieu des deux utilisés dans TLS 1.2. Dans TLS 1.2 et les versions antérieures, le premier aller-retour comprend les étapes de rencontre. Le deuxième aller-retour comprend l'Exchange des clés et le changement du type de chiffrement d'asymétrique à symétrique. Enfin, la reprise à temps zéro aller-retour (0-RTT) permet la génération d'une clé de reprise maîtresse.