7. Considérations de sécurité

Ce document entier discute des pratiques de sécurité affectant directement les applications utilisant le protocole TLS. Cette section contient des considérations de sécurité plus larges liées aux technologies utilisées conjointement avec ou par TLS. Le lecteur est renvoyé aux sections Considérations de sécurité de TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246] et DTLS 1.2 [RFC6347] pour plus de contexte.

7.1. Validation du nom d'hôte

Les auteurs d'applications doivent noter que certaines implémentations TLS ne valident pas les noms d'hôtes. Si l'implémentation TLS qu'ils utilisent ne valide pas les noms d'hôtes, les auteurs pourraient devoir écrire leur propre code de validation ou envisager d'utiliser une implémentation TLS différente.

Il est noté que les exigences concernant la validation du nom d'hôte (et, en général, la liaison entre la couche TLS et le protocole qui s'exécute au-dessus) varient entre les différents protocoles. Pour HTTPS, ces exigences sont définies par les sections 4.3.3, 4.3.4 et 4.3.5 de [RFC9110].

La validation du nom d'hôte est critique pour la sécurité pour tous les cas d'utilisation courants de TLS. Sans cela, TLS garantit que le certificat est valide et garantit la possession de la clé privée mais ne garantit pas que la connexion se termine au point de terminaison souhaité. Les lecteurs sont renvoyés à [RFC6125] pour plus de détails concernant la validation générique du nom d'hôte dans le contexte TLS. De plus, ce RFC contient une longue liste de protocoles d'application, dont certains implémentent une politique très différente de HTTPS.

Si le nom d'hôte est découvert indirectement et de manière non sécurisée (par exemple, par une requête DNS en clair pour un enregistrement SRV ou Mail Exchange (MX)), il NE DEVRAIT PAS être utilisé comme identifiant de référence [RFC6125] même lorsqu'il correspond au certificat présenté. Cette clause ne s'applique pas si le nom d'hôte est découvert de manière sécurisée (pour plus de discussion, voir [RFC7673] et [RFC7672]).

La validation du nom d'hôte s'applique généralement uniquement au certificat "d'entité finale" feuille. Naturellement, afin d'assurer une authentification appropriée dans le contexte de la PKI, les clients d'application doivent vérifier le chemin de certification complet conformément à [RFC5280].

7.2. AES-GCM

La section 4.2 recommande l'utilisation de l'algorithme de chiffrement authentifié AES-GCM. Veuillez vous référer à la section 6 de [RFC5288] pour les considérations de sécurité qui s'appliquent spécifiquement à AES-GCM lorsqu'il est utilisé avec TLS.

7.2.1. Réutilisation de nonce dans TLS 1.2

L'existence de piles TLS déployées qui réutilisent par erreur le nonce AES-GCM est documentée dans [Boeck2016], montrant qu'il existe un risque réel que AES-GCM soit implémenté de manière non sécurisée et rendant ainsi les sessions TLS qui utilisent une suite de chiffrement AES-GCM vulnérables à des attaques telles que [Joux2006]. (Voir les enregistrements [CVE] : CVE-2016-0270, CVE-2016-10213, CVE-2016-10212 et CVE-2017-5933.)

Bien que ce problème ait été résolu dans TLS 1.3, qui applique une méthode déterministe pour générer des nonces à partir des numéros de séquence d'enregistrement et des secrets partagés pour toutes ses suites de chiffrement AEAD (y compris AES-GCM), les implémentations TLS 1.2 pourraient toujours choisir leurs propres méthodes de génération de nonce (potentiellement non sécurisées).

Il est donc RECOMMANDÉ que les implémentations TLS 1.2 utilisent le numéro de séquence de 64 bits pour remplir la partie nonce_explicit du nonce GCM, comme décrit dans les deux premiers paragraphes de la section 5.3 de [RFC8446]. Cette recommandation plus forte met à jour la section 3 de [RFC5288], qui spécifie que l'utilisation de numéros de séquence de 64 bits pour remplir le champ nonce_explicit est facultative.

Nous notons qu'au moment de la rédaction, il n'y a pas de suites de chiffrement définies pour des algorithmes résistants à la réutilisation de nonce tels que AES-GCM-SIV [RFC8452].

7.3. Confidentialité persistante

La confidentialité persistante (également appelée "confidentialité persistante parfaite" ou "PFS" et définie dans [RFC4949]) est une défense contre un attaquant qui enregistre des conversations chiffrées où les clés de session sont uniquement chiffrées avec les clés à long terme des parties communicantes.

Si l'attaquant parvenait à obtenir ces clés à long terme à un moment ultérieur, les clés de session et donc toute la conversation pourraient être déchiffrées.

Dans le contexte de TLS et DTLS, une telle compromission des clés à long terme n'est pas entièrement invraisemblable. Cela peut se produire, par exemple, en raison de :

• Un client ou un serveur attaqué par un autre vecteur d'attaque, et la clé privée récupérée.

• Une clé à long terme récupérée à partir d'un appareil qui a été vendu ou autrement mis hors service sans effacement préalable.

• Une clé à long terme utilisée sur un appareil comme clé par défaut [Heninger2012].

• Une clé générée par un tiers de confiance comme une CA et récupérée plus tard auprès de lui par extorsion ou compromission [Soghoian2011].

• Une percée cryptographique ou l'utilisation de clés asymétriques avec une longueur insuffisante [Kleinjung2010].

• Des attaques d'ingénierie sociale contre les administrateurs système.

• Collecte de clés privées à partir de sauvegardes insuffisamment protégées.

La confidentialité persistante garantit dans de tels cas qu'il n'est pas possible pour un attaquant de déterminer les clés de session même si l'attaquant a obtenu les clés à long terme quelque temps après la conversation. Elle protège également contre un attaquant qui est en possession des clés à long terme mais reste passif pendant la conversation.

La confidentialité persistante est généralement obtenue en utilisant le schéma Diffie-Hellman pour dériver les clés de session. Le schéma Diffie-Hellman permet aux deux parties de conserver des secrets privés et d'envoyer des paramètres sur le réseau sous forme de puissances modulaires sur certains groupes cycliques. Les propriétés du soi-disant problème du logarithme discret (DLP) permettent aux parties de dériver les clés de session sans qu'un indiscret puisse le faire. Il n'existe actuellement aucune attaque connue contre DLP si des paramètres suffisamment grands sont choisis. Une variante du schéma Diffie-Hellman utilise des courbes elliptiques au lieu de l'arithmétique modulaire proposée à l'origine. Compte tenu de l'état actuel de la technique, Elliptic Curve Diffie-Hellman semble être plus efficace, permet des longueurs de clé plus courtes et laisse moins de liberté pour les erreurs d'implémentation que Diffie-Hellman à champ fini.

Malheureusement, de nombreuses suites de chiffrement TLS/DTLS ont été définies sans fonctionnalité de confidentialité persistante, par exemple TLS_RSA_WITH_AES_256_CBC_SHA256. Ce document préconise donc l'utilisation stricte de chiffrements à confidentialité persistante uniquement.

7.4. Réutilisation de l'exposant Diffie-Hellman

Pour des raisons de performance, il n'est pas rare que les implémentations TLS réutilisent les exposants Diffie-Hellman et Elliptic Curve Diffie-Hellman sur plusieurs connexions. Une telle réutilisation peut entraîner des problèmes de sécurité majeurs :

• Si les exposants sont réutilisés trop longtemps (dans certains cas, même aussi peu que quelques heures), un attaquant qui accède à l'hôte peut déchiffrer les connexions précédentes. En d'autres termes, la réutilisation de l'exposant annule les effets de la confidentialité persistante.

• Les implémentations TLS qui réutilisent les exposants devraient tester la clé publique DH qu'elles reçoivent pour l'appartenance au groupe, afin d'éviter certaines attaques connues. Ces tests ne sont pas normalisés dans TLS au moment de la rédaction, bien que des conseils généraux dans ce domaine soient fournis par [NIST.SP.800-56A] et disponibles dans de nombreuses implémentations de protocoles.

• Dans certaines conditions, l'utilisation de clés DH à champ fini statiques, ou de clés DH à champ fini éphémères qui sont réutilisées sur plusieurs connexions, peut conduire à des attaques temporelles (telles que celles décrites dans [RACCOON]) sur les secrets partagés utilisés dans l'échange de clés Diffie-Hellman.

• Une attaque "courbe invalide" peut être montée contre Elliptic Curve DH si la victime ne vérifie pas que le point reçu se trouve sur la courbe correcte. Si la victime réutilise les secrets DH, l'attaquant peut répéter le sondage en faisant varier les points pour récupérer le secret complet (voir [Antipa2003] et [Jager2015]).

Pour répondre à ces préoccupations :

• Les implémentations TLS NE DEVRAIENT PAS utiliser de clés DH à champ fini statiques et NE DEVRAIENT PAS réutiliser les clés DH à champ fini éphémères sur plusieurs connexions.

• Les implémentations de serveur qui souhaitent réutiliser les clés Elliptic Curve DH DEVRAIENT soit utiliser une "courbe sûre" [SAFECURVES] (par exemple, X25519), soit effectuer les vérifications décrites dans [NIST.SP.800-56A] sur les points reçus.

7.5. Révocation de certificat

Les considérations et recommandations suivantes représentent l'état actuel de la technique concernant la révocation de certificats, même si aucune solution complète et efficace n'existe pour le problème de la vérification du statut de révocation des certificats de clé publique courants [RFC5280] :

• La révocation de certificat est un outil important lors de la récupération d'attaques sur l'implémentation TLS ainsi que dans les cas de certificats mal émis. Les implémentations TLS DOIVENT implémenter une stratégie pour se méfier des certificats révoqués.

• Bien que les listes de révocation de certificats (CRL) soient le mécanisme le plus largement pris en charge pour distribuer des informations de révocation, elles présentent des défis de mise à l'échelle connus qui limitent leur utilité, malgré des solutions de contournement telles que les CRL partitionnées et les CRL delta. Le plus moderne [CRLite] et la suite Let's Revoke [LetsRevoke] s'appuient sur la disponibilité des journaux Certificate Transparency [RFC9162] et une compression agressive pour permettre une utilisation pratique de l'infrastructure CRL, mais au moment de la rédaction, aucune des deux solutions n'est déployée pour le traitement de la révocation côté client à grande échelle.

• Les mécanismes propriétaires qui intègrent des listes de révocation dans la base de données de configuration du navigateur Web ne peuvent pas s'étendre au-delà des quelques serveurs Web les plus utilisés.

• Le protocole OCSP (Online Certification Status Protocol) [RFC6960] dans sa forme de base présente des problèmes de mise à l'échelle et de confidentialité. De plus, les clients "échouent généralement en douceur", ce qui signifie qu'ils n'interrompent pas la connexion TLS si le serveur OCSP ne répond pas. (Cependant, cela pourrait être une solution de contournement pour éviter les attaques par déni de service si un répondeur OCSP est mis hors ligne.) Pour une enquête récente sur l'état du déploiement OCSP dans la PKI Web, voir [Chung18].

• L'extension TLS Certificate Status Request (section 8 de [RFC6066]), communément appelée "agrafage OCSP", résout les problèmes opérationnels avec OCSP. Cependant, elle est toujours inefficace en présence d'un attaquant actif sur le chemin car l'attaquant peut simplement ignorer la demande du client pour une réponse OCSP agrafée.

• [RFC7633] définit une extension de certificat qui indique que les clients doivent s'attendre à des réponses OCSP agrafées pour le certificat et doivent interrompre le handshake ("échec dur") si une telle réponse n'est pas disponible.

• L'agrafage OCSP tel qu'utilisé dans TLS 1.2 ne s'étend pas aux certificats intermédiaires au sein d'une chaîne de certificats. L'extension Multiple Certificate Status [RFC6961] répond à cette lacune, mais elle a connu peu de déploiement et avait été dépréciée par [RFC8446]. Par conséquent, bien que cette extension ait été recommandée pour TLS 1.2 dans [RFC7525], elle n'est plus recommandée par ce document.

• TLS 1.3 (section 4.4.2.1 de [RFC8446]) permet l'association d'informations OCSP avec des certificats intermédiaires en utilisant une extension de la structure CertificateEntry. Cependant, l'utilisation de cette facilité reste peu pratique car de nombreuses autorités de certification (CA) ne publient pas d'OCSP pour les certificats CA ou publient des rapports OCSP avec une durée de vie trop longue pour être utiles.

• Les CRL et OCSP dépendent tous deux d'une connectivité relativement fiable à Internet, qui pourrait ne pas être disponible pour certains types de nœuds. Un exemple courant est celui des appareils nouvellement provisionnés qui doivent établir une connexion sécurisée afin de démarrer pour la première fois.

Pour les cas d'utilisation courants des certificats de clé publique dans TLS, les serveurs DEVRAIENT prendre en charge ce qui suit comme une meilleure pratique étant donné l'état actuel de la technique et comme base pour une éventuelle solution future : OCSP [RFC6960] et l'agrafage OCSP utilisant l'extension status_request définie dans [RFC6066]. Notez que le mécanisme exact pour intégrer l'extension status_request diffère entre TLS 1.2 et 1.3. En tant que question de politique locale, les opérateurs de serveur PEUVENT demander aux CA d'émettre des certificats must-staple [RFC7633] pour le serveur et/ou pour l'authentification du client, mais nous recommandons d'examiner les conditions opérationnelles avant de décider de cette approche.

Les considérations de cette section ne s'appliquent pas aux scénarios où l'enregistrement de ressource TLSA DNS-Based Authentication of Named Entities (DANE) [RFC6698] est utilisé pour signaler à un client quel certificat un serveur considère comme valide et bon à utiliser pour les connexions TLS.