Aller au contenu principal

5. Considérations de sécurité

Cette section traite des problèmes de sécurité liés à l'utilisation d'un ticket. Les tickets doivent être authentifiés et chiffrés pour empêcher toute modification ou écoute clandestine par un attaquant. Plusieurs attaques décrites ci-dessous seront possibles si cela n'est pas fait avec soin.

Les implémentations devraient veiller à ce que le traitement des tickets n'augmente pas le risque de déni de service décrit ci-dessous.

5.1. Invalidation des sessions​

La spécification TLS exige que les sessions TLS soient invalidées lorsque des erreurs se produisent. [CSSC] examine en détail les implications de sécurité de cette exigence. Dans l'analyse présentée dans cet article, le fait de ne pas invalider les sessions ne présente pas de risque de sécurité. Cela s'explique par le fait que le handshake TLS utilise une fonction non réversible pour dériver les clés d'une session, de sorte que les informations relatives à une session ne donnent aucun avantage pour attaquer le master secret ou une autre session. Si un mécanisme d'invalidation de session est utilisé, l'implémentation devrait vérifier l'intégrité du ticket avant d'utiliser son contenu pour invalider une session, afin de garantir qu'un attaquant ne puisse pas invalider une session de son choix.

5.2. Tickets volés​

Un espion ou un attaquant de type homme du milieu (man-in-the-middle) peut obtenir le ticket et tenter de l'utiliser pour établir une session avec le serveur ; toutefois, comme le ticket est chiffré et que l'attaquant ne connaît pas la clé secrète, un ticket volé n'aide pas un attaquant à reprendre une session. Un serveur TLS DOIT (MUST) utiliser un chiffrement fort et une protection d'intégrité forte pour le ticket afin d'empêcher un attaquant d'utiliser un mécanisme de force brute pour obtenir le contenu du ticket.

5.3. Tickets falsifiés​

Un utilisateur malveillant pourrait falsifier ou altérer un ticket afin de reprendre une session, de prolonger sa durée de vie, d'usurper l'identité d'un autre utilisateur ou d'obtenir des privilèges supplémentaires. Cette attaque n'est pas possible si le ticket est protégé à l'aide d'un algorithme de protection d'intégrité fort tel que HMAC-SHA-256 avec clé.

5.4. Attaques par déni de service​

Le champ key_name défini dans le format de ticket recommandé aide le serveur à rejeter efficacement les tickets qu'il n'a pas émis. Cependant, un adversaire pourrait stocker ou générer un grand nombre de tickets à envoyer au serveur TLS pour vérification. Afin de minimiser la possibilité d'un déni de service, la vérification du ticket devrait être légère (par exemple, en utilisant des algorithmes cryptographiques à clé symétrique efficaces).

5.5. Gestion des clés de protection des tickets​

Une description complète de la gestion des clés utilisées pour protéger le ticket sort du cadre de ce document. Une liste de pratiques RECOMMANDÉES (RECOMMENDED) est donnée ci-dessous.

  • Les clés devraient être générées de manière sûre en suivant les recommandations relatives à l'aléa (randomness) de [RFC4086].

  • Les clés et les algorithmes de protection cryptographique devraient offrir une robustesse d'au moins 128 bits. Certaines suites de chiffrement (ciphersuites) et applications peuvent exiger une protection cryptographique d'une robustesse supérieure à 128 bits.

  • Les clés ne devraient pas être utilisées à d'autres fins que la génération et la vérification des tickets.

  • Les clés devraient être changées régulièrement.

  • Les clés devraient être changées si le format du ticket ou les algorithmes de protection cryptographique changent.

5.6. Durée de vie des tickets​

Le serveur TLS contrôle la durée de vie du ticket. Les serveurs déterminent la durée de vie acceptable en fonction des exigences opérationnelles et de sécurité des environnements dans lesquels ils sont déployés. La durée de vie du ticket peut être supérieure à la durée de vie de 24 heures recommandée dans [RFC4346]. Les clients TLS peuvent recevoir une indication de la durée de vie du ticket. Comme la durée de vie d'un ticket peut être non spécifiée, un client dispose de sa propre politique locale qui détermine quand il écarte les tickets.

5.7. Formats de ticket et mécanismes de distribution alternatifs​

Si le format de ticket ou le mécanisme de distribution défini dans ce document n'est pas utilisé, le plus grand soin doit alors être apporté à l'analyse de la sécurité de la solution. En particulier, si des informations confidentielles, telles qu'une clé secrète, sont transférées au client, cela DOIT (MUST) être fait au moyen d'une communication sécurisée afin d'empêcher les attaquants d'obtenir ou de modifier la clé. De plus, l'intégrité et la confidentialité du ticket DOIVENT (MUST) être protégées par de solides techniques cryptographiques afin de prévenir une atteinte à la sécurité du système.

5.8. Confidentialité de l'identité, anonymat et non-corrélation​

Ce document impose que le contenu du ticket soit protégé en confidentialité afin d'éviter toute fuite de son contenu, tel que des informations relatives à l'utilisateur. À ce titre, il empêche la divulgation d'informations potentiellement sensibles transportées dans le ticket.

L'échange de handshake initial, qui a servi à obtenir le ticket, pourrait ne pas garantir la confidentialité de l'identité du client, en raison des propriétés de TLS. Une autre menace de sécurité pertinente est la capacité d'un adversaire situé sur le chemin (on-path) à observer plusieurs handshakes TLS dans lesquels le même ticket est utilisé, et donc à conclure qu'ils appartiennent aux mêmes points de terminaison de communication. Les concepteurs d'applications qui utilisent le mécanisme de ticket décrit dans ce document devraient tenir compte du fait que la non-corrélation (unlinkability) [ANON] n'est pas nécessairement assurée.

Bien qu'une discussion complète de ces sujets sorte du cadre de ce document, il convient de noter qu'il est possible d'émettre un ticket à l'aide d'un handshake de renégociation TLS (renegotiation) qui se produit après qu'un tunnel sécurisé a été établi par un handshake précédent. Cela peut aider à traiter certains problèmes de confidentialité et de non-corrélation dans certains environnements.