Introduction

Le protocole TLS est une des solutions les plus répandues pour la protection des flux réseau. Dans ce modèle client–serveur, les données applicatives sont encapsulées de manière à assurer la confidentialité et l’intégrité des échanges. Le serveur est nécessairement authentifié, et des fonctions additionnelles permettent l’authentification du client lorsqu’un tel besoin a été identifié. Depuis l’apparition de son prédécesseur SSL en 1995, TLS a été adopté par de nombreux acteurs de l’Internet pour sécuriser le trafic lié aux sites web et à la messagerie électronique. Il s’agit par ailleurs d’une solution privilégiée pour la protection de flux d’infrastructure internes. Pour ces raisons, le protocole et ses implémentations font l’objet d’un travail de recherche conséquent. Au fil des années, plusieurs vulnérabilités ont été découvertes, motivant le développement de corrections et de contre-mesures pour prévenir la compromission des échanges. Le déploiement TLS apportant le plus d’assurance en matière de sécurité repose donc sur l’utilisation de logiciels mis à jour, mais aussi sur l’ajustement des paramètres du protocole en fonction du contexte. Les explications apportées par le présent guide sont complétées par plusieurs recommandations visant à atteindre un niveau de sécurité conforme à l’état de l’art, notamment au sujet des suites cryptographiques à retenir.

Déroulement des sessions TLS

Le développement du protocole TLS a suivi plusieurs itérations depuis la conception du protocole SSL, désormais obsolète. Le processus de standardisation est à la charge de l’IETF. Les valeurs numériques des différents paramètres sont référencées par l’IANA. Les messages transmis par l’intermédiaire du protocole TLS sont appelés records . Ils sont généralement encapsulés dans des segments TCP, protocole chargé d’assurer les fonctionnalités de transport réseau telles que l’acquittement à la réception de données. Pour les protocoles à datagrammes, comme UDP, une variante DTLS a été définie. Il existe quatre types de record, expliqués ci-après :

  • handshake
  • change_cipher_spec
  • application_data
  • alert.

Par souci d’interopérabilité, les spécifications permettent aux deux parties impliquées de négocier la version du protocole qu’ils adopteront communément. Ce paramètre est établi au cours d’une phase TLS handshake qui précède la protection effective des échanges. De même, les spécifications autorisent l’utilisation de différentes combinaisons d’algorithmes cryptographiques. La suite cryptographique retenue pour la session est déterminée grâce aux messages de type handshake, en complément des messages de type change_cipher_spec qui signalent l’échéance de sa mise en œuvre. La figure illustre la négociation de ces paramètres dans un cas générique. Elle fait intervenir les échanges suivants entre le client et le serveur :

session TLS ANSSI

  1. le client initie une requête en envoyant un message de type ClientHello, contenant notamment les suites cryptographiques qu’il prend en charge
  2. le serveur répond par un ServerHello qui contient la suite retenue
  3. le serveur envoie un message Certificate, qui contient en particulier sa clé publique au sein d’un certificat numérique
  4. le serveur transmet dans un ServerKeyExchange une valeur éphémère qu’il signe à l’aide de la clé privée associée à la clé publique précédente
  5. le serveur manifeste sa mise en attente avec un ServerHelloDone
  6. après validation du certificat et vérification de la signature précédente, le client poursuit l’échange de clés en choisissant à son tour une valeur éphémère et en la transmettant dans un ClientKeyExchange
  7. leclientsignalel’adoptiondelasuitenégociéeavecun ChangeCipherSpec
  8. le client envoie un Finished, premier message protégé selon la suite cryptographique avec les secrets issus de l’échange de clés éphémères précédent
  9. le serveur signale l’adoption de la même suite avec un ChangeCipherSpec
  10. le serveur envoie à son tour un Finished, son premier message sécurisé.

Le cas générique décrit ici sous-entend l’adoption d’une des suites cryptographiques qui assurent la propriété de confidentialité persistante, ou PFS. Celle-ci consiste à prévenir le déchiffrement de messages de sessions passées quand bien même la clé privée liée au certificat du serveur serait compromise, en négociant un secret éphémère à l’aide d’un échange de clés Diffie–Hellman. L’authentification du serveur repose alors sur la signature inscrite dans le ServerKeyExchange. Les spécifications du protocole définissent par ailleurs plusieurs messages supplémentaires et extensions qui permettent d’encadrer et d’enrichir la protection des communications. Dans les contextes où un tel besoin aurait été identifié, le serveur est notamment en mesure de demander l’authentification du client au niveau TLS par l’intermédiaire d’un message CertificateRequest. En ce qui concerne les extensions, un ClientHello peut par exemple contenir des informations additionnelles relatives aux courbes elliptiques prises en charge par le client pour effectuer des calculs ECC. À l’issue du handshake, le client et le serveur disposent d’un secret partagé, le premaster secret, calculé grâce aux éléments contenus dans le ServerKeyExchange et le ClientKeyExchange. Le premaster secret est dérivé de part et d’autre en un même master secret qui prend en compte les aléas contenus dans le ClientHello et le ServerHello. Enfin, le master secret est à son tour dérivé afin de générer les clés qui permettent de protéger les données applicatives en confidentialité et en intégrité, avant de les encapsuler dans des messages de type application_data. Les spécifications permettent de redéfinir les paramètres de sécurité ou encore de rafraîchir les clés de chiffrement sans interrompre la session TLS, à l’aide d’un nouveau handshake. Cette renégociation de session peut être déclenchée à l’initiative du client par l’intermédiaire d’un nouveau ClientHello. Elle peut aussi être sollicitée par le serveur à l’aide d’un message HelloRequest. Les messages de type alert permettent quant à eux de signaler des anomalies observées au cours du handshake ou bien de l’échange de données applicatives. Certains messages constituent juste des avertissements, tandis que d’autres appellent à une terminaison immédiate de la session TLS. Plusieurs codes d’alerte existent, qui permettent par exemple de signaler qu’un certificat transmis n’est pas valide, ou encore que le contrôle d’intégrité d’un record échoué.

Infrastructures de gestion de clés

La validité des certificats envoyés pendant la négociation TLS est cruciale pour la vérification de l’identité des parties communicantes. L’ensemble des mécanismes et des entités qui garantissent cette validité et la maintiennent forment une infrastructure de gestion de clés. Pour un certificat conforme à la norme X.509 qui est suivie dans le cadre de TLS, l’assurance que la clé publique qu’il contient appartienne effectivement au serveur qu’il annonce en tant que sujet (généralement sous la forme d’un nom de domaine) repose sur la transmission de confiance depuis une autorité déjà reconnue jusqu’au serveur en question. Les liens de confiance successifs établis par chaque autorité de certification impliquée sont matérialisés par des signatures cryptographiques apposées aux différents certificats. Ainsi, le message Certificate dont est extraite la clé publique sur laquelle s’appuient les secrets de session contient en réalité une chaîne de certificats, dont le client attend qu’elle forme un lien depuis une racine de confiance jusqu’au serveur interrogé. Ces racines sont généralement listées dans des registres : les magasins de certificats.

Pour plus de renseignements, vous pouvez consulter la suite de l’article à cette adresse : guide_tls_v1.1