3. Recommandations générales

Cette section fournit des recommandations générales sur l'utilisation sécurisée de TLS. Les recommandations relatives aux suites de chiffrement sont discutées dans la section suivante.

3.1. Versions du protocole

3.1.1. Versions du protocole SSL/TLS

Il est important à la fois d'arrêter d'utiliser les anciennes versions moins sécurisées de SSL/TLS et de commencer à utiliser des versions modernes et plus sécurisées ; par conséquent, voici les recommandations concernant les versions du protocole TLS/SSL :

• Les implémentations NE DOIVENT PAS négocier SSL version 2.

  Raison : Aujourd'hui, SSLv2 est considéré comme non sécurisé [RFC6176].

• Les implémentations NE DOIVENT PAS négocier SSL version 3.

  Raison : SSLv3 [RFC6101] était une amélioration par rapport à SSLv2 et a comblé certaines failles de sécurité importantes, mais ne prenait pas en charge les suites de chiffrement fortes. SSLv3 ne prend pas en charge les extensions TLS, dont certaines (par exemple, renegotiation_info [RFC5746]) sont critiques pour la sécurité. De plus, avec l'émergence de l'attaque Padding Oracle On Downgraded Legacy Encryption (POODLE) [POODLE], SSLv3 est maintenant largement reconnu comme fondamentalement non sécurisé. Voir [RFC7568] pour plus de détails.

• Les implémentations NE DOIVENT PAS négocier TLS version 1.0 [RFC2246].

  Raison : TLS 1.0 (publié en 1999) ne prend pas en charge de nombreuses suites de chiffrement modernes et fortes. De plus, TLS 1.0 manque d'un vecteur d'initialisation (IV) par enregistrement pour les suites de chiffrement basées sur le chaînage de blocs de chiffrement (CBC) et ne met pas en garde contre les erreurs de remplissage courantes. Cette recommandation et d'autres dans cette section sont conformes à [RFC8996].

• Les implémentations NE DOIVENT PAS négocier TLS version 1.1 [RFC4346].

  Raison : TLS 1.1 (publié en 2006) est une amélioration de la sécurité par rapport à TLS 1.0 mais ne prend toujours pas en charge certaines suites de chiffrement plus fortes qui ont été introduites avec la standardisation de TLS 1.2 en 2008, y compris les suites de chiffrement recommandées pour TLS 1.2 par ce document (voir la section 4.2 ci-dessous).

• Les implémentations DOIVENT prendre en charge TLS 1.2 [RFC5246].

  Raison : TLS 1.2 est implémenté et déployé plus largement que TLS 1.3 à l'heure actuelle, et lorsque les recommandations de ce document sont suivies pour atténuer les attaques connues, l'utilisation de TLS 1.2 est aussi sûre que l'utilisation de TLS 1.3. Pour la plupart des protocoles d'application qui réutilisent TLS et DTLS, il n'y a pas de besoin immédiat de migrer uniquement vers TLS 1.3. En effet, comme de nombreux clients d'application dépendent de bibliothèques TLS ou de systèmes d'exploitation qui ne prennent pas encore en charge TLS 1.3, déprécier proactivement TLS 1.2 introduirait des problèmes d'interopérabilité importants, nuisant ainsi à la sécurité plus qu'elle ne l'aiderait. Néanmoins, il est prévu qu'une future version de ce BCP dépréciera l'utilisation de TLS 1.2 lorsque cela sera approprié.

• Les implémentations DEVRAIENT prendre en charge TLS 1.3 [RFC8446] et, si elles sont implémentées, DOIVENT préférer négocier TLS 1.3 par rapport aux versions antérieures de TLS.

  Raison : TLS 1.3 est une refonte majeure du protocole et résout de nombreux problèmes de sécurité avec TLS 1.2. Dans la mesure où une implémentation prend en charge TLS 1.2 (même si elle utilise par défaut TLS 1.3), elle DOIT suivre les recommandations concernant TLS 1.2 spécifiées dans ce document.

• Les nouveaux protocoles de transport qui intègrent le protocole de handshake TLS/DTLS et/ou la couche d'enregistrement DOIVENT utiliser uniquement TLS/DTLS 1.3 (par exemple, QUIC [RFC9001] a adopté cette approche). Les nouveaux protocoles d'application qui utilisent TLS/DTLS pour le chiffrement de canal ou de session DOIVENT s'intégrer aux versions 1.2 et 1.3 de TLS/DTLS ; néanmoins, dans de rares cas où une large interopérabilité n'est pas une préoccupation, les concepteurs de protocoles d'application PEUVENT choisir de renoncer à TLS 1.2.

  Raison : Le déploiement sécurisé de TLS 1.3 est nettement plus facile et moins sujet aux erreurs que le déploiement sécurisé de TLS 1.2. Lors de la conception d'un nouveau protocole de transport sécurisé tel que QUIC, il n'y a aucune raison de prendre en charge TLS 1.2. En revanche, les nouveaux protocoles d'application qui réutilisent TLS doivent prendre en charge à la fois TLS 1.3 et TLS 1.2 afin de tirer parti de la prise en charge des bibliothèques sous-jacentes ou du système d'exploitation pour les deux versions.

Ce BCP s'applique à TLS 1.3, TLS 1.2 et aux versions antérieures. Il n'est pas sûr pour les lecteurs de supposer que les recommandations de ce BCP s'appliquent à toute version future de TLS.

3.1.2. Versions du protocole DTLS

DTLS, une adaptation de TLS pour les datagrammes UDP, a été introduit lors de la publication de TLS 1.1. Voici les recommandations concernant DTLS :

• Les implémentations NE DOIVENT PAS négocier DTLS version 1.0 [RFC4347].

  La version 1.0 de DTLS correspond à la version 1.1 de TLS (voir ci-dessus).

• Les implémentations DOIVENT prendre en charge DTLS 1.2 [RFC6347].

  La version 1.2 de DTLS correspond à la version 1.2 de TLS (voir ci-dessus). (Il n'y a pas de version 1.1 de DTLS.)

• Les implémentations DEVRAIENT prendre en charge DTLS 1.3 [RFC9147] et, si elles sont implémentées, DOIVENT préférer négocier DTLS version 1.3 par rapport aux versions antérieures de DTLS.

  La version 1.3 de DTLS correspond à la version 1.3 de TLS (voir ci-dessus).

3.1.3. Repli vers des versions inférieures

Les clients TLS/DTLS 1.2 NE DOIVENT PAS se replier sur des versions TLS antérieures, car ces versions ont été dépréciées [RFC8996]. Par conséquent, le mécanisme de valeur de suite de chiffrement de signalisation (SCSV) de protection contre le déclassement [RFC7507] n'est plus nécessaire pour les clients. De plus, TLS 1.3 implémente un nouveau mécanisme de négociation de version.

3.2. Strict TLS

Les recommandations suivantes sont fournies pour aider à prévenir le "SSL Stripping" et l'injection de commande STARTTLS (attaques qui sont résumées dans [RFC7457]) :

• De nombreux protocoles d'application existants ont été conçus avant que l'utilisation de TLS ne devienne courante. Ces protocoles prennent généralement en charge TLS de l'une des deux manières suivantes : soit via un port séparé pour la communication TLS uniquement (par exemple, le port 443 pour HTTPS), soit via une méthode de mise à niveau dynamique d'un canal non chiffré vers un canal protégé par TLS (par exemple, STARTTLS, qui est utilisé dans des protocoles tels que IMAP et XMPP). Quel que soit le mécanisme de protection du canal de communication (port TLS uniquement ou mise à niveau dynamique), ce qui compte, c'est l'état final du canal. Lorsqu'un protocole définit à la fois une méthode de mise à niveau dynamique et une méthode séparée TLS uniquement, alors la méthode séparée TLS uniquement DOIT être prise en charge par les implémentations et DOIT être configurée par les administrateurs pour être utilisée de préférence à la méthode de mise à niveau dynamique. Lorsqu'un protocole ne prend en charge qu'une méthode de mise à niveau dynamique, les implémentations DOIVENT fournir un moyen aux administrateurs de définir une politique locale stricte interdisant l'utilisation du texte clair en l'absence d'un canal TLS négocié, et les administrateurs DOIVENT utiliser cette politique.

• Les implémentations client et serveur HTTP destinées à être utilisées sur le World Wide Web (voir section 5) DOIVENT prendre en charge le champ d'en-tête HTTP Strict Transport Security (HSTS) [RFC6797] afin que les serveurs Web puissent annoncer qu'ils sont prêts à accepter des clients TLS uniquement. Les serveurs Web DEVRAIENT utiliser HSTS pour indiquer qu'ils sont prêts à accepter des clients TLS uniquement, à moins qu'ils ne soient déployés de telle manière que l'utilisation de HSTS affaiblirait en fait la sécurité globale (par exemple, il peut être problématique d'utiliser HSTS avec des certificats auto-signés, comme décrit dans la section 11.3 de [RFC6797]). Des technologies similaires existent pour les protocoles d'application non HTTP, telles que Mail Transfer Agent Strict Transport Security (MTA-STS) pour les agents de transfert de courrier [RFC8461] et les méthodes basées sur DNS-Based Authentication of Named Entities (DANE) [RFC6698] pour SMTP [RFC7672] et XMPP [RFC7712].

Raison : La combinaison d'une communication non protégée et d'une communication protégée par TLS ouvre la voie au SSL Stripping et à des attaques similaires, car une partie initiale de la communication n'est pas protégée en intégrité et peut donc être manipulée par un attaquant dont le but est de maintenir la communication en clair.

3.3. Compression

Afin d'aider à prévenir les attaques liées à la compression (résumées à la section 2.6 de [RFC7457]) lors de l'utilisation de TLS 1.2, les implémentations et les déploiements NE DEVRAIENT PAS prendre en charge la compression au niveau TLS (section 6.2.2 de [RFC5246]) ; la seule exception est lorsque le protocole d'application en question a été prouvé comme n'étant pas ouvert à de telles attaques. Cependant, même dans ce cas, une extrême prudence est de mise en raison du potentiel d'attaques futures liées à la compression TLS. Plus spécifiquement, le protocole HTTP est connu pour être vulnérable aux attaques liées à la compression. (Cette recommandation s'applique uniquement à TLS 1.2, car la compression a été supprimée de TLS 1.3.)

Raison : La compression TLS a fait l'objet d'attaques de sécurité telles que l'attaque Compression Ratio Info-leak Made Easy (CRIME).

Les implémenteurs doivent noter que la compression à des niveaux de protocole plus élevés peut permettre à un attaquant actif d'extraire des informations en clair de la connexion. L'attaque Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) est un de ces cas. Ces problèmes ne peuvent être atténués qu'en dehors de TLS et sont donc hors de la portée de ce document. Voir la section 2.6 de [RFC7457] pour plus de détails.

3.3.1. Compression de certificat

Les chaînes de certificats occupent souvent la majeure partie des octets transmis lors du handshake. Afin de gérer leur taille, certaines ou toutes les méthodes suivantes peuvent être employées (voir aussi la section 4 de [RFC9191] pour d'autres suggestions) :

• Limiter le nombre de noms ou d'extensions.

• Utiliser des clés avec de petites représentations de clé publique, comme l'Elliptic Curve Digital Signature Algorithm (ECDSA).

• Utiliser la compression de certificat.

Pour réaliser ce dernier, TLS 1.3 définit l'extension compress_certificate dans [RFC8879]. Voir aussi la section 5 de [RFC8879] pour les considérations de sécurité et de confidentialité associées à son utilisation. Pour éviter tout doute, les attaques de style CRIME sur la compression TLS ne s'appliquent pas à la compression de certificat.

En raison de la forte probabilité d'interférence des boîtiers intermédiaires, la compression dans le style de [RFC8879] n'a pas été rendue disponible dans TLS 1.2. En théorie, l'extension cached_info définie dans [RFC7924] pourrait être utilisée, mais elle n'est pas prise en charge assez largement pour être considérée comme une alternative pratique.

3.4. Reprise de session TLS

La reprise de session réduit considérablement le nombre de handshakes TLS complets et constitue donc une fonctionnalité de performance essentielle pour la plupart des déploiements.

La reprise de session sans état avec des tickets de session est une stratégie populaire. Pour TLS 1.2, elle est spécifiée dans [RFC5077]. Pour TLS 1.3, un mécanisme plus sécurisé basé sur l'utilisation d'une clé pré-partagée (PSK) est décrit dans la section 4.6.1 de [RFC8446]. Voir [Springall16] pour une étude quantitative des risques induits par les "raccourcis" cryptographiques TLS, y compris la reprise de session.

Lorsqu'elle est utilisée, les informations de reprise DOIVENT être authentifiées et chiffrées pour empêcher toute modification ou écoute par un attaquant. D'autres recommandations s'appliquent aux tickets de session :

• Un chiffrement fort DOIT être utilisé lors du chiffrement du ticket (au moins aussi fort que la suite de chiffrement TLS principale).

• Les clés de chiffrement de ticket DOIVENT être changées régulièrement, par exemple une fois par semaine, afin de ne pas annuler les avantages de la confidentialité persistante (voir la section 7.3 pour plus de détails sur la confidentialité persistante). Les anciennes clés de chiffrement de ticket DOIVENT être détruites à la fin de la période de validité.

• Pour des raisons similaires, la validité du ticket de session DOIT être limitée à une durée raisonnable (par exemple, la moitié de la validité de la clé de chiffrement de ticket).

• TLS 1.2 ne fait pas rouler la clé de session au sein d'une seule session. Ainsi, pour empêcher une attaque où la clé de chiffrement de ticket du serveur est volée et utilisée pour déchiffrer tout le contenu d'une session (annulant le concept de confidentialité persistante), un serveur TLS 1.2 NE DEVRAIT PAS reprendre des sessions trop anciennes, par exemple des sessions qui sont ouvertes depuis plus de deux périodes de rotation de clé de chiffrement de ticket.

Raison : La reprise de session est un autre type de handshake TLS et doit donc être aussi sécurisée que le handshake initial. Ce document (section 4) recommande l'utilisation de suites de chiffrement qui offrent une confidentialité persistante, c'est-à-dire qui empêchent un attaquant qui obtient un accès momentané au point de terminaison TLS (client ou serveur) et à ses secrets de lire les communications passées ou futures. Les tickets doivent être gérés de manière à ne pas annuler cette propriété de sécurité.

TLS 1.3 offre l'option puissante de confidentialité persistante même au sein d'une connexion de longue durée qui est périodiquement reprise. La section 2.2 de [RFC8446] recommande que les clients DEVRAIENT envoyer un "key_share" lors de l'initiation de la reprise de session. Afin d'obtenir une confidentialité persistante, ce document recommande que les implémentations de serveur DEVRAIENT sélectionner le mode d'échange de clé PSK "psk_dhe_ke" et répondre avec un "key_share" pour effectuer un échange Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) à chaque reprise de session. Comme alternative plus performante, les implémentations de serveur PEUVENT s'abstenir de répondre avec un "key_share" jusqu'à ce qu'un certain temps (par exemple, mesuré en heures) se soit écoulé depuis le dernier échange ECDHE ; cela implique que l'opération "key_share" ne se produirait pas pour la majorité présumée des demandes de reprise de session (qui se produiraient en quelques heures) tout en assurant la confidentialité persistante pour les sessions de plus longue durée.

La reprise de session TLS introduit des problèmes potentiels de confidentialité où le serveur est capable de suivre le client, dans certains cas indéfiniment. Voir [Sy2018] pour plus de détails.

3.5. Renégociation dans TLS 1.2

Les recommandations de cette section s'appliquent uniquement à TLS 1.2, car la renégociation a été supprimée de TLS 1.3.

La renégociation dans TLS 1.2 est un handshake qui établit de nouveaux paramètres cryptographiques pour une session existante. Le mécanisme existait dans TLS 1.2 et dans les versions antérieures du protocole et a été amélioré à la suite de plusieurs attaques majeures, notamment une attaque par injection de texte clair, CVE-2009-3555 [CVE].

Les clients et serveurs TLS 1.2 DOIVENT implémenter l'extension renegotiation_info, telle que définie dans [RFC5746].

Les clients TLS 1.2 DOIVENT envoyer renegotiation_info dans le Client Hello. Si le serveur ne reconnaît pas l'extension, le client DOIT générer une alerte fatale handshake_failure avant de terminer la connexion.

Raison : Il n'est pas sûr pour un client de se connecter à un serveur TLS 1.2 qui ne prend pas en charge renegotiation_info, que l'un ou l'autre des points de terminaison implémente réellement la renégociation ou non. Voir aussi la section 4.1 de [RFC5746].

Une attaque connexe résultant de paramètres de session TLS mal authentifiés est un Triple Handshake [Triple-Handshake]. Pour faire face à cette attaque, les implémentations TLS 1.2 DOIVENT prendre en charge l'extension extended_master_secret définie dans [RFC7627].

3.6. Authentification après handshake

La renégociation dans TLS 1.2 a été (partiellement) remplacée dans TLS 1.3 par des mécanismes distincts d'authentification après handshake et de mise à jour de clé. Dans le contexte de protocoles qui multiplexent les requêtes sur une seule connexion (comme HTTP/2 [RFC9113]), l'authentification après handshake présente les mêmes problèmes que la renégociation TLS 1.2. Les protocoles multiplexés DEVRAIENT suivre les conseils fournis pour HTTP/2 dans la section 9.2.3 de [RFC9113].

3.7. Server Name Indication (SNI)

Les implémentations TLS DOIVENT prendre en charge l'extension Server Name Indication (SNI) définie dans la section 3 de [RFC6066] pour les protocoles de niveau supérieur qui en bénéficieraient, y compris HTTPS. Cependant, l'utilisation réelle de SNI dans des circonstances particulières est une question de politique locale. Au moment de la rédaction, une technologie de chiffrement du SNI (appelée Encrypted Client Hello) est en cours d'élaboration au sein du groupe de travail TLS [TLS-ECH]. Une fois cette méthode normalisée et largement implémentée, il sera probablement approprié de recommander son utilisation dans une future version de ce BCP.

Raison : SNI prend en charge le déploiement de plusieurs serveurs virtuels protégés par TLS sur une seule adresse, et permet donc une sécurité fine pour ces serveurs virtuels, en permettant à chacun d'avoir son propre certificat. Cependant, SNI divulgue également le domaine cible pour une connexion donnée ; cette fuite d'information sera fermée par l'utilisation de TLS Encrypted Client Hello une fois cette méthode normalisée.

Afin de prévenir les attaques décrites dans [ALPACA], un serveur qui ne reconnaît pas le nom de serveur présenté NE DEVRAIT PAS poursuivre le handshake et DEVRAIT plutôt échouer avec une alerte fatale unrecognized_name(112). Notez que cette recommandation met à jour la section 3 de [RFC6066], qui déclarait :

| Si le serveur a compris l'extension ClientHello mais ne reconnaît pas le nom du serveur, le serveur DEVRAIT prendre l'une des deux mesures suivantes : soit interrompre le handshake en envoyant une alerte fatale unrecognized_name(112), soit poursuivre le handshake.

Les clients DEVRAIENT interrompre le handshake si le serveur reconnaît l'extension SNI mais présente un certificat avec un nom d'hôte différent de celui envoyé par le client.

3.8. Application-Layer Protocol Negotiation (ALPN)

Les implémentations TLS (côté client et côté serveur) DOIVENT prendre en charge l'extension Application-Layer Protocol Negotiation (ALPN) [RFC7301].

Afin de prévenir les attaques "inter-protocoles" résultant de l'échec à garantir qu'un message destiné à être utilisé dans un protocole ne puisse pas être confondu avec un message destiné à être utilisé dans un autre protocole, il est conseillé aux serveurs d'appliquer strictement le comportement prescrit dans la section 3.2 de [RFC7301] :

| Dans le cas où le serveur ne prend en charge aucun des protocoles annoncés par le client, le serveur DEVRA répondre avec une alerte fatale 'no_application_protocol'.

Les clients DEVRAIENT interrompre le handshake si le serveur reconnaît l'extension ALPN mais ne sélectionne pas un protocole dans la liste du client. Ne pas le faire peut entraîner des attaques telles que celles décrites dans [ALPACA].

Les développeurs de protocoles sont fortement encouragés à enregistrer un identifiant ALPN pour leurs protocoles. Cela s'applique aussi bien aux nouveaux protocoles qu'aux protocoles bien établis ; cependant, comme ces derniers peuvent avoir une base installée importante, une application stricte de l'utilisation d'ALPN peut ne pas être réalisable lorsqu'un identifiant ALPN est enregistré pour un protocole bien établi.

3.9. Déploiement multi-serveurs

Les déploiements impliquant plusieurs serveurs ou services peuvent augmenter la taille de la surface d'attaque pour TLS. Deux scénarios sont intéressants :

1. Déploiements dans lesquels plusieurs services gèrent le même nom de domaine via différents protocoles (par exemple, HTTP et IMAP). Dans ce cas, un attaquant pourrait être en mesure de diriger un point de terminaison de connexion vers le service offrant un protocole différent et de monter une attaque inter-protocoles. Dans une attaque inter-protocoles, le client et le serveur croient utiliser des protocoles différents, ce que l'attaquant pourrait exploiter si les messages envoyés dans un protocole sont interprétés comme des messages dans l'autre protocole avec des effets indésirables (voir [ALPACA] pour des informations plus détaillées sur cette classe d'attaques). Pour atténuer cette menace, les fournisseurs de services DEVRAIENT déployer ALPN (voir section 3.8). De plus, dans la mesure du possible, ils DEVRAIENT s'assurer que plusieurs services gérant le même nom de domaine offrent des niveaux de sécurité équivalents, conformes aux recommandations de ce document ; de telles mesures DEVRAIENT inclure la gestion des configurations sur plusieurs serveurs TLS et des protections contre la compromission des identifiants détenus par ces serveurs.

2. Déploiements dans lesquels plusieurs serveurs fournissant le même service ont des configurations TLS différentes. Dans ce cas, un attaquant pourrait être en mesure de diriger un point de terminaison de connexion vers un serveur ayant une configuration TLS plus facilement exploitable (voir [DROWN] pour des informations plus détaillées sur cette classe d'attaques). Pour atténuer cette menace, les fournisseurs de services DEVRAIENT s'assurer que tous les serveurs fournissant le même service offrent des niveaux de sécurité équivalents, conformes aux recommandations de ce document.

3.10. Données Zero Round-Trip Time (0-RTT) dans TLS 1.3

La fonctionnalité de données précoces 0-RTT est nouvelle dans TLS 1.3. Elle offre une latence réduite lors de la reprise des connexions TLS, au coût potentiel de certaines propriétés de sécurité. Par conséquent, elle nécessite une attention particulière de la part des implémenteurs, tant du côté serveur que du côté client. En général, cela s'étend à la bibliothèque TLS ainsi qu'aux couches de protocole au-dessus d'elle.

Pour HTTP sur TLS, reportez-vous à [RFC8470] pour obtenir des conseils.

Pour QUIC sur TLS, reportez-vous à la section 9.2 de [RFC9001].

Pour les autres protocoles, des conseils génériques sont donnés à la section 8 et à l'annexe E.5 de [RFC8446]. Pour paraphraser l'annexe E.5, les applications DOIVENT éviter cette fonctionnalité à moins qu'une spécification explicite n'existe pour le protocole d'application en question afin de clarifier quand le 0-RTT est approprié et sécurisé. Cela peut prendre la forme d'un RFC de l'IETF, d'une norme non-IETF ou d'une documentation associée à un protocole non standard.