Aller au contenu principal

1. Introduction

Transport Layer Security (TLS) et Datagram Transport Layer Security (DTLS) sont utilisés pour protéger les données échangées sur une grande variété de protocoles d'application, notamment HTTP [RFC9112] [RFC9113], IMAP [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP [RFC5321] et Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. Ces protocoles utilisent à la fois le protocole de handshake TLS ou DTLS et la couche d'enregistrement TLS ou DTLS. Bien que le protocole de handshake TLS puisse également être utilisé avec différentes couches d'enregistrement pour définir des protocoles de transport sécurisés (l'exemple le plus marquant étant QUIC [RFC9000]), ces protocoles de transport ne sont pas directement concernés par ce document ; néanmoins, bon nombre des recommandations ici peuvent s'appliquer dans la mesure où ces protocoles utilisent le protocole de handshake TLS.

Au cours des années précédant 2015, l'industrie a été témoin d'attaques graves contre TLS et DTLS, notamment des attaques sur les suites de chiffrement les plus couramment utilisées et leurs modes de fonctionnement. Par exemple, les algorithmes de chiffrement AES-CBC [RFC3602] et RC4 [RFC7465], qui étaient autrefois les chiffrements les plus largement déployés, ont été attaqués dans le contexte de TLS. Des informations détaillées sur les attaques connues avant 2015 sont fournies dans un document d'accompagnement [RFC7457] de la version précédente des recommandations TLS [RFC7525], ce qui aidera le lecteur à comprendre la raison d'être des recommandations fournies ici. Ce document n'a pas été mis à jour de concert avec celui-ci ; au lieu de cela, les attaques plus récentes sont décrites dans ce document, tout comme les mesures d'atténuation pour ces attaques.

La communauté TLS a réagi aux attaques décrites dans [RFC7457] de plusieurs manières :

  • Des conseils détaillés ont été publiés sur l'utilisation de TLS 1.2 [RFC5246] et DTLS 1.2 [RFC6347] ainsi que des versions antérieures du protocole. Ces conseils sont inclus dans le [RFC7525] original et en grande partie conservés dans cette version révisée ; notez que ces conseils ont été en grande partie adoptés par l'industrie depuis la publication du RFC 7525 en 2015.

  • Les versions de TLS antérieures à 1.2 ont été dépréciées [RFC8996].

  • La version 1.3 de TLS [RFC8446] a été publiée, suivie de la version 1.3 de DTLS [RFC9147] ; ces versions atténuent ou résolvent en grande partie les attaques décrites.

Ceux qui implémentent et déploient TLS et les protocoles basés sur TLS ont besoin de conseils sur la manière de les utiliser en toute sécurité. Ce document fournit des conseils pour les services déployés ainsi que pour les implémentations logicielles, en supposant que l'implémenteur s'attend à ce que son code soit déployé dans les environnements définis à la section 5. En ce qui concerne le déploiement, ce document vise un large public, à savoir tous les déployeurs qui souhaitent ajouter une authentification (qu'elle soit unidirectionnelle ou mutuelle), une confidentialité et une protection de l'intégrité des données à leurs communications.

Les recommandations ci-incluses prennent en considération la sécurité de divers mécanismes, leur maturité technique et leur interopérabilité, ainsi que leur prévalence dans les implémentations au moment de la rédaction. À moins qu'il ne soit explicitement indiqué qu'une recommandation s'applique uniquement à TLS ou uniquement à DTLS, chaque recommandation s'applique à la fois à TLS et à DTLS.

Ce document tente de minimiser les nouveaux conseils pour les implémentations TLS 1.2, et l'approche globale consiste à encourager les systèmes à migrer vers TLS 1.3. Cependant, ce n'est pas toujours pratique. Les attaques nouvellement découvertes, ainsi que les changements dans l'écosystème, ont nécessité certaines nouvelles exigences qui s'appliquent aux environnements TLS 1.2. Celles-ci sont résumées à l'annexe A.

Naturellement, de futures attaques sont probables, et ce document ne peut pas y répondre. Ceux qui implémentent et déploient TLS/DTLS et les protocoles basés sur TLS/DTLS sont vivement invités à prêter attention aux développements futurs. En particulier, bien que l'on sache que la création d'ordinateurs quantiques aura un impact significatif sur la sécurité des primitives cryptographiques et des technologies qui les utilisent, la cryptographie post-quantique est actuellement un travail en cours et il est trop tôt pour faire des recommandations ; une fois que les spécifications pertinentes seront normalisées à l'IETF ou ailleurs, ce document devra être mis à jour pour refléter les meilleures pratiques à ce moment-là.

Comme indiqué, la spécification TLS 1.3 résout bon nombre des vulnérabilités énumérées dans ce document. Un système qui déploie TLS 1.3 devrait avoir moins de vulnérabilités que TLS 1.2 ou inférieur. Par conséquent, ce document remplace [RFC7525], avec un objectif explicite d'encourager la migration de la plupart des utilisations de TLS 1.2 vers TLS 1.3.

Ce sont des recommandations minimales pour l'utilisation de TLS dans la grande majorité des scénarios d'implémentation et de déploiement, à l'exception du TLS non authentifié (voir section 5). D'autres spécifications faisant référence à ce document peuvent avoir des exigences plus strictes liées à un ou plusieurs aspects du protocole, en fonction de leurs circonstances particulières (par exemple, pour une utilisation avec un protocole d'application spécifique) ; lorsque c'est le cas, il est conseillé aux implémenteurs de respecter ces exigences plus strictes. De plus, ce document fournit un plancher, pas un plafond : dans la mesure du possible, les administrateurs de services sont encouragés à aller au-delà du support minimum disponible dans les implémentations pour fournir la sécurité la plus forte possible. Par exemple, sur la base des connaissances sur la base installée pour un protocole d'application existant et d'une analyse coûts-avantages concernant la force de la sécurité par rapport à l'interopérabilité, un fournisseur de services donné pourrait décider de désactiver complètement TLS 1.2 et de n'offrir que TLS 1.3.

Les connaissances de la communauté sur la force des divers algorithmes et les attaques réalisables peuvent changer rapidement, et l'expérience montre qu'un document de meilleures pratiques actuelles (BCP) sur la sécurité est une déclaration ponctuelle. Les lecteurs sont invités à rechercher les errata ou les mises à jour qui s'appliquent à ce document.

Ce document met à jour [RFC5288] compte tenu de l'attaque [Boeck2016]. Voir la section 7.2.1 pour les détails.

Ce document met à jour [RFC6066] compte tenu de l'attaque [ALPACA]. Voir la section 3.7 pour les détails.