TLS 1.3, la dernière version du protocole TLS publiée en août 2018 par l’IETF (RFC 8446), est promise à un bel avenir. Elle répond aux besoins actuels du « tout https » plébiscité par les géants du web, tout en assurant des performances accrues et une meilleure sécurité que TLS 1.2.

De plus en plus de navigateurs et de serveurs web offrent des mises à jour compatibles avec cette version. Dans quelques années TLS 1.3 sera sans aucun doute le protocole de sécurité des communications le plus répandu. Le point sur les améliorations et les nouvelles fonctionnalités de TLS 1.3.

TLS est le protocole le plus répandu pour sécuriser les communications entre différents systèmes informatiques. Il garantit :

• L’authenticité : l’identité des communicants est vérifiée ;
• La confidentialité : les données échangées ne sont visibles que pour les participants ;
• L’intégrité : les données transmises ne peuvent être altérées par des acteurs malveillants.

TLS 1.3 : plus de sécurité

Aujourd’hui, activer le protocole TLS 1.2 n’est pas suffisant pour garantir une communication sécurisée. Il admet en effet plusieurs algorithmes cryptographiques désormais obsolètes : SHA-1, RC4, DES, 3DES, AES-CBC, MD5, groupes arbitraires Diffie-Hellman… Une mauvaise configuration du serveur en termes de choix d’algorithmes pourrait ainsi faciliter des attaques malveillantes.

Au contraire, TLS 1.3 désactive ou améliore les algorithmes obsolètes admis dans TLS 1.2, et inclut de nouveaux algorithmes de manière à proposer uniquement des suites de chiffrement AEAD (Authenticated Encryption with Associated Data), une forme de chiffrement assurant la confidentialité et l’authenticité des données.

La nouvelle version du protocole version vise aussi à proposer une alternative aux algorithmes soutenus par le NIST, qui a été mis en cause dans l’affaiblissement volontaire de systèmes cryptographiques suite à sa relation avec la NSA. La version 1.3 offre la possibilité d’utiliser à la fois les algorithmes issus des travaux de D. J. Bernstein (EdDSA, ChaCha20, x25519 entre autres), les algorithmes classiques (tels que AES ou ECDSA) et les courbes du NIST (P-256, P-384, P-512…).

L’algorithme de dérivation des clés évolue aussi. La version précédente s’appuie sur une fonction pseudo-aléatoire (PRF – pseudorandom function) tandis qu’en TLS 1.3 les clés sont générées avec HKDF (extract et expand), une fonction de dérivation des clés basée sur HMAC.

La mise à jour apporte également des évolutions liées aux mécanismes d’échanges de clé. Désormais, la confidentialité persistante ou PFS (Perfect Forward Secrecy) est obligatoire. Le TLS 1.2 nécessitait des paramétrages supplémentaires pour mettre en œuvre cette fonctionnalité. Pour rappel, la PFS est une propriété qui garantit que la découverte par un adversaire de la clé privée d’un correspondant ne compromet pas la confidentialité des communications passées. Ce choix a d’ailleurs été beaucoup critiqué par les Etats et certaines entreprises qui s’opposaient fortement à cette nouvelle version rendant la surveillance plus difficile.

Une autre évolution majeure du protocole est la nouvelle conception du Handshake TLS. Avec TLS 1.2, la première partie de cette phase, la négociation des suites cryptographiques, est faite en clair. Cela laisse une brèche aux attaques « downgrade », durant lesquelles les attaquants forcent l’utilisation d’algorithmes faibles. De même, les extensions envoyées dans le message ServerHello (Cf. schéma Handshake) ne sont pas chiffrées. Avec TLS 1.3, le serveur signe tous les messages transmis lors du Handshake, incluant la négociation des algorithmes, de plus tous les messages envoyés après le ServerHello ainsi que toutes les extensions sont chiffrés.

Ce nouveau mode de fonctionnement, combiné à l’extension ESNI (Encrypted Server Name Indication), empêche les observateurs tiers de détecter le site web auquel un utilisateur tente d’accéder. Cela empêche effectivement des outils de surveillance de voir ce que font les internautes en ligne, certains Etats bloquant même cette utilisation de TLS.

TLS 1.3 : plus de rapidité

TLS 1.2 nécessite au moins deux allers-retours, sans compter les messages SYN, SYN-ACK, afin de finaliser le Handshake et de monter le canal sécurisé. TLS 1.3 lui réduit l’échange à un seul aller-retour et accélère la connexion, comme on peut le voir ci-dessous :

Au premier appel, le client envoie au serveur le message ClientHello, qui contient :

• Le nonce (nombre aléatoire pour éviter les attaques de rejeu)
• La version du protocole TLS utilisé
• La liste des algorithmes symétriques et HKDF supportés,
• Et soit un ensemble de clés partagées Diffie-Hellman, soit un ensemble de labels de clés pré-partagées ou un ensemble des deux.

Le client peut en plus envoyer la liste d’extensions souhaitées.

Le serveur traite le message ClientHello et détermine les paramètres cryptographiques appropriés pour la connexion.

Le serveur répond ensuite avec un ServerHello indiquant les paramètres de connexion négociés :

• Si des clés Diffie-Hellman sont utilisées pour l’échange de clé, le message ServerHello répond avec l’extension « key share » avec la clé partagée Diffie-Hellman du serveur.
• Si des clés pré-partagées sont utilisées pour l’échange de clé, le message ServerHello répond avec l’extension « pre_shared_key » indiquant le label de la clé pré-partagée à utiliser.
• Il est aussi envisageable d’utiliser les deux modes en même temps.

Le serveur peut envoyer deux messages supplémentaires pour répondre aux extensions demandées par le client, et pour demander l’authentification du client.

Le serveur envoie ensuite son certificat (mais il est possible de définir d’autres moyens d’authentification comme PSK) et une signature de tous les échanges précédents avec la clé privée associée au certificat serveur (CertificateVerify).

Enfin, l’échange se termine avec un « finished » qui est, concrètement, un calcul de MAC (Message Authentication Code) sur l’ensemble du Handshake.

Fin du Handshake :

Le client peut envoyer son certificat et la signature du Handshake avec sa clé privée (CertificateVerify) si c’est demandé par le serveur, et termine l’échange avec un message « finished » contenant un calcul de MAC sur l’ensemble du Handshake.

Légende :

* : facultatif , [] : chiffré

Note : cette cinématique présente le cas nominal où les données envoyées par le client sont acceptées par le serveur au premier échange (clés partagées entre autres). Si ce n’est pas le cas, le serveur peut envoyer des messages supplémentaires pour demander au client de fournir les éléments supportés.

Zero Round Trip Time : encore plus de rapidité

Pour accélérer davantage la connexion, il est possible d’activer la fonctionnalité Zero Round Trip Time (0-RTT). Cette fonctionnalité permet, comme son nom l’indique, de réduire le Handshake à zéro échange.

Quand un client et un serveur partagent une clé pré-partagée, importée manuellement ou calculée lors d’un précédent Handshake, TLS 1.3 permet au client d’envoyer des données applicatives dès le premier échange. Il s’agit d’early data. La clé pré-partagée est utilisée pour authentifier le serveur et chiffrer les données envoyées lors du premier échange.

Cette fonctionnalité présente cependant un risque, puisqu’un attaquant pourrait utiliser une attaque de rejeu, c’est-à-dire récupérer le premier message envoyé, pour se faire passer pour un client. Cette fonction n’est heureusement pas activée par défaut.

Le protocole TLS est devenu un indispensable pour sécuriser les connexions, et avec lui, les certificats numériques nécessaires à son fonctionnement. Ces certificats possèdent une durée de vie limitée, et afin de continuer à garder une connexion sécurisée et éviter les arrêts de service, il faut apprendre à les gérer. Au fil des années, le nombre et les restrictions des certificats numériques n’ont fait qu’augmenter, rendant la tâche plus difficile pour les équipes techniques opérationnelles.

C’est ce que nous proposons avec notre solution BerryCert : identifier l’ensemble des certificats présents dans les systèmes d’information, les prendre en charge et les renouveler automatiquement, afin de minimiser les risques d’incidents similaires.