11. Considérations de sécurité

11.1. Considérations de sécurité pour server_name

Si un serveur implémente des domaines de sécurité de niveau nom, il DEVRAIT correctement gérer les tentatives par les clients de résoudre des noms dans le mauvais domaine de sécurité. Un avertissement NE DEVRAIT PAS être utilisé ; un serveur DEVRAIT soit refuser la connexion avec une alerte fatale appropriée, soit procéder en utilisant le domaine de sécurité qu'il a sélectionné.

Notez que les noms de serveur dans les extensions server_name ne sont pas authentifiés par la poignée de main TLS. Il n'y a aucune garantie que le nom de serveur présenté par le client correspond au nom dans le certificat du serveur, et il n'y a aucune authentification du nom lui-même. Les applications qui s'appuient sur l'authentification du serveur DOIVENT effectuer leurs propres vérifications d'identité (telles que celles décrites dans [RFC6125]) en utilisant le nom présenté dans le certificat du serveur.

Il peut y avoir des cas où un serveur héberge plusieurs domaines et où il serait inapproprié pour un domaine d'apprendre que le client tentait de contacter un autre domaine. Dans de tels cas, il peut être préférable pour les serveurs de répondre de manière identique indépendamment du nom du serveur ; par exemple, un serveur multi-domaine pourrait renvoyer un certificat valide pour tous les domaines qu'il héberge, ou pourrait renvoyer la même alerte dans tous les cas. Cela empêche un observateur de déterminer lequel des domaines du serveur un client tentait de contacter.

Il existe un risque de déni de service si un serveur charge de nombreux certificats différents basés sur le nom du serveur de l'extension server_name. Le serveur DEVRAIT implémenter des mécanismes pour limiter la charge causée par le traitement de l'extension server_name, tels que la mise en cache des certificats ou la limitation du nombre de certificats différents qu'il chargera.

11.2. Considérations de sécurité pour max_fragment_length

La réduction de la taille maximale des fragments peut augmenter la vulnérabilité aux attaques par canal auxiliaire, car elle peut révéler des informations sur le modèle de trafic. Par exemple, si une application envoie une petite quantité de données sensibles, les attaquants pourraient être en mesure de déduire la quantité de données simplement en observant le nombre de fragments.

Les implémentations DEVRAIENT considérer les risques de canal auxiliaire lors de la négociation de tailles de fragment réduites, en particulier pour les applications traitant des données sensibles.

La négociation de tailles de fragment plus petites peut également exposer les implémentations à des attaques par fragmentation où un attaquant tente de submerger l'implémentation avec de nombreux petits fragments. Les implémentations DEVRAIENT avoir des limites appropriées sur le nombre de fragments qu'elles traiteront.

11.3. Considérations de sécurité pour client_certificate_url

Lorsque des URLs de certificat client sont utilisées, le serveur obtient les certificats d'un emplacement réseau externe. Cela introduit plusieurs risques de sécurité :

Attaques par usurpation d'URL : Un attaquant pourrait fournir des URLs qui pointent vers des certificats qu'il contrôle, permettant potentiellement une authentification non autorisée. Les serveurs DOIVENT :

• Valider que le certificat obtenu depuis l'URL est signé par une CA de confiance.
• Effectuer toutes les vérifications de certificat standard requises par [RFC5246].
• Valider que le client possède la clé privée correspondant à la clé publique du certificat (cela est fait pendant la poignée de main TLS).

Attaques de type homme-du-milieu : Si un attaquant peut intercepter ou modifier la communication entre le serveur et l'URL du certificat, il pourrait substituer un certificat différent. Pour atténuer ce risque :

• Les serveurs DEVRAIENT utiliser HTTPS pour obtenir les certificats depuis les URLs.
• Lorsqu'un hachage de certificat est fourni, les serveurs DOIVENT vérifier le hachage du certificat obtenu correspond au hachage fourni.

Attaques par déni de service : Un client malveillant pourrait fournir des URLs qui :

• Pointent vers des serveurs qui sont lents à répondre ou ne répondent pas du tout.
• Pointent vers des ressources extrêmement grandes.
• Sont conçues pour causer un traitement excessif côté serveur.

Pour atténuer ces risques, les serveurs DEVRAIENT :

• Implémenter des délais d'attente appropriés pour la récupération des URLs.
• Limiter la taille maximale des certificats qu'ils récupéreront.
• Limiter le nombre de tentatives de récupération qu'ils effectueront.
• Implémenter une limitation de débit pour les demandes de récupération de certificat.

Problèmes de confidentialité : L'utilisation des URLs de certificat révèle au serveur hébergeant l'URL que le client tente de s'authentifier auprès d'un service particulier. Cela pourrait permettre le suivi des activités du client. Les clients DEVRAIENT considérer ces implications de confidentialité lors de l'utilisation de l'extension client_certificate_url.

Exposition des informations du certificat : Si les URLs de certificat sont accessibles publiquement sans authentification, cela pourrait exposer des informations de certificat qui devraient être privées. Les clients DEVRAIENT considérer si leurs certificats contiennent des informations sensibles et choisir des mécanismes d'hébergement appropriés.

Attaques par rejeu de hachage : Si un serveur met en cache les certificats basés sur les hachages, un attaquant pourrait potentiellement réutiliser un ancien hachage si le certificat mis en cache existe toujours. Pour atténuer :

• Les serveurs DEVRAIENT implémenter des politiques d'expiration de cache appropriées.
• Les serveurs DOIVENT vérifier que les certificats mis en cache sont toujours valides et non révoqués.

11.4. Considérations de sécurité pour trusted_ca_keys

L'extension trusted_ca_keys révèle au serveur quelles autorités de certification sont approuvées par le client. Cela pourrait révéler des informations sur l'environnement de confiance du client, ce qui pourrait être utilisé pour l'empreinte digitale ou le profilage.

De plus, si un client fournit une longue liste de CA de confiance, cela pourrait :

• Créer un risque de déni de service en causant un traitement excessif côté serveur.
• Révéler des informations sur les partenaires commerciaux ou les relations organisationnelles du client.

Les clients DEVRAIENT considérer soigneusement s'il faut utiliser cette extension et, dans l'affirmative, quelles CA inclure dans la liste. Les serveurs DEVRAIENT implémenter des limites appropriées sur le nombre de CA qu'ils traiteront.

11.5. Considérations de sécurité pour truncated_hmac

L'extension truncated_hmac réduit la longueur du MAC de 160 bits (pour SHA-1) à 80 bits. Cela réduit considérablement la force de sécurité du MAC.

Un MAC de 80 bits offre environ 2^80 opérations de résistance contre les attaques par recherche exhaustive, ce qui est considéré comme marginalement sûr par les normes modernes. À mesure que la puissance de calcul augmente, cette marge de sécurité diminue.

Les considérations suivantes s'appliquent :

• Les implémentations NE DEVRAIENT PAS utiliser truncated_hmac pour des applications de haute sécurité.
• L'extension truncated_hmac NE DEVRAIT être utilisée que lorsque les contraintes de bande passante sont significatives et que le risque de sécurité réduit est acceptable.
• Même avec des MACs tronqués, toutes les autres considérations de sécurité TLS s'appliquent toujours.
• Les implémentations DEVRAIENT considérer l'utilisation de suites de chiffrement avec des MACs plus courts de manière native (comme celles utilisant des chiffrements AEAD) plutôt que d'utiliser truncated_hmac.

Les attaques potentielles contre des MACs tronqués incluent :

Attaques par collision : Avec un MAC de 80 bits, un attaquant a une probabilité non négligeable (environ 2^40 tentatives) de trouver une collision en utilisant une attaque d'anniversaire. Cependant, exploiter une collision de MAC dans TLS nécessiterait que l'attaquant puisse manipuler le texte en clair et observer les MACs, ce qui est généralement difficile.

Attaques par contrefaçon : Un attaquant essayant de contrefaire un MAC aurait besoin d'environ 2^80 tentatives, ce qui est encore computationnellement coûteux mais dans le domaine du possible pour des adversaires bien financés.

À la lumière de ces considérations, l'utilisation de truncated_hmac devrait être soigneusement évaluée en fonction du modèle de menace de l'application spécifique.

11.6. Considérations de sécurité pour status_request

Les considérations de sécurité pour l'extension status_request sont discutées en détail dans la Section 8.4. Les points clés incluent :

• Les serveurs peuvent servir des réponses OCSP obsolètes ou incorrectes.
• Les clients doivent effectuer une validation complète des réponses OCSP reçues.
• Les serveurs compromis pourraient omettre les informations de statut pour les certificats révoqués.
• L'extension améliore la confidentialité en évitant que les clients contactent directement les répondeurs OCSP.

11.7. Considérations générales de sécurité

Négociation d'extension : Le mécanisme de négociation d'extension lui-même doit être sécurisé. Les attaquants ne devraient pas être en mesure :

• De forcer l'utilisation ou la non-utilisation de extensions particulières par la suppression ou l'injection de messages.
• D'apprendre des informations sensibles en observant quelles extensions sont négociées.

Le mécanisme de poignée de main TLS protège contre la modification de la négociation d'extension via le message Finished, qui couvre tous les messages de poignée de main incluant les extensions.

Incompatibilités d'extension : Les clients et les serveurs doivent gérer correctement les situations où :

• Une extension est comprise par une partie mais pas par l'autre.
• Différentes versions d'une extension sont prises en charge.
• Des extensions conflictuelles sont demandées.

Les implémentations DEVRAIENT échouer de manière sécurisée lorsqu'elles rencontrent des extensions incompréhensibles ou conflictuelles.

Considérations de performance et de sécurité : Certaines extensions peuvent avoir des implications de performance qui affectent la sécurité. Par exemple :

• Des tailles de fragment plus petites peuvent augmenter la charge de traitement.
• L'obtention de certificats depuis des URLs peut introduire des retards.
• Le traitement de grandes listes de CA de confiance peut consommer des ressources.

Les implémentations DEVRAIENT considérer l'équilibre entre les avantages de fonctionnalité et les risques potentiels de déni de service ou de dégradation de performance.

Considérations de confidentialité : Plusieurs extensions révèlent des informations sur le client ou le serveur :

• server_name révèle quel serveur le client tente de contacter.
• trusted_ca_keys révèle l'environnement de confiance du client.
• client_certificate_url peut révéler les activités du client au serveur hébergeant les URLs.

Les implémentations DEVRAIENT permettre aux utilisateurs de contrôler quelles informations sont révélées à travers ces extensions, en particulier dans les environnements où la confidentialité est une préoccupation.

Extensibilité future : À mesure que de nouvelles extensions sont définies, chacune doit être soigneusement évaluée pour :

• Les implications de sécurité de l'extension elle-même.
• Les interactions avec les extensions existantes.
• L'impact sur le modèle de sécurité global de TLS.

Les créateurs de nouvelles extensions DEVRAIENT fournir une analyse de sécurité approfondie dans leurs spécifications.