6. Considérations de sécurité

6.1. Les messages HTTP ne sont pas entièrement protégés

Ce document spécifie un mécanisme d'intégrité des données qui protège les données de représentation ou le contenu HTTP, mais pas les champs d'en-tête et de fin HTTP, contre certains types de corruption.

Les champs d'intégrité ne sont pas destinés à être une protection générale contre la falsification malveillante des messages HTTP. En l'absence de mécanismes de sécurité supplémentaires, un acteur malveillant sur le chemin peut soit supprimer entièrement une valeur de condensat, soit la remplacer par une nouvelle valeur de condensat calculée sur des données de représentation ou un contenu manipulés. Cette attaque peut être atténuée en combinant les mécanismes décrits dans ce document avec d'autres approches telles que la sécurité de la couche de transport (TLS) ou les signatures numériques (par exemple, les signatures de message HTTP [SIGNATURES]).

6.2. Intégrité de bout en bout

Les champs d'intégrité peuvent aider à détecter la modification des données de représentation ou du contenu en raison d'erreurs d'implémentation, de "proxys de transformation" indésirables (voir la section 7.7 de [HTTP]), ou d'autres actions lorsque les données traversent plusieurs sauts ou frontières du système. Même un mécanisme simple pour l'intégrité des données de représentation de bout en bout est précieux car un agent utilisateur peut valider que la récupération de la ressource a réussi avant de la transmettre à un analyseur HTML, un lecteur vidéo, etc., pour analyse.

Notez que l'utilisation de ces mécanismes seuls ne fournit pas l'intégrité de bout en bout des messages HTTP sur plusieurs sauts, car les métadonnées pourraient être manipulées à n'importe quel stade. Les méthodes de protection des métadonnées sont discutées dans la section 6.3.

6.3. Utilisation dans les signatures

Les signatures numériques sont largement utilisées avec les sommes de contrôle pour fournir l'identification certaine de l'origine d'un message [FIPS186-5]. De telles signatures peuvent protéger un ou plusieurs champs HTTP et il y a des considérations supplémentaires lorsque les champs d'intégrité sont inclus dans cet ensemble.

Il n'y a aucune restriction sur le type ou le format de signature numérique avec lequel les champs d'intégrité peuvent être utilisés. Une approche possible consiste à les combiner avec les signatures de message HTTP [SIGNATURES].

Les condensats dépendent explicitement des "métadonnées de représentation" (par exemple, les valeurs de Content-Type, Content-Encoding, etc.). Une signature qui protège les champs d'intégrité mais pas d'autres "métadonnées de représentation" peut exposer la communication à la falsification. Par exemple, un acteur pourrait manipuler la valeur du champ Content-Type et provoquer un échec de validation du condensat chez le destinataire, empêchant l'application d'accéder à la représentation. Une telle attaque consomme les ressources des deux points de terminaison. Voir aussi la section 3.2.

Les signatures sont susceptibles d'être considérées comme un cadre conflictuel lors de l'application des champs d'intégrité ; voir la section 5. Repr-Digest offre une possibilité intéressante lorsqu'il est combiné avec des signatures. Dans le scénario où il n'y a pas de contenu à envoyer, le condensat d'une chaîne vide peut être inclus dans le message et, s'il est signé, peut aider le destinataire à détecter si du contenu a été ajouté à la suite d'un accident ou d'une manipulation intentionnelle. Le scénario inverse est également pris en charge ; inclure un champ d'intégrité pour le contenu et le signer peut aider un destinataire à détecter où le contenu a été supprimé.

Toute mutilation des champs d'intégrité peut affecter la validation de la signature. Des exemples d'une telle mutilation incluent la déduplication des condensats ou la combinaison de différentes valeurs de champ (voir la section 5.2 de [HTTP]).

6.4. Utilisation dans les champs de fin

Avant d'envoyer des champs d'intégrité dans une section de fin, l'expéditeur doit tenir compte du fait que les intermédiaires sont explicitement autorisés à supprimer toute fin (voir la section 6.5.2 de [HTTP]).

Lorsque les champs d'intégrité sont utilisés dans une section de fin, les valeurs de champ sont reçues après le contenu. Le traitement anticipé du contenu avant la section de fin empêche la validation du condensat, conduisant éventuellement au traitement de données non valides.

L'un des avantages de l'utilisation des champs d'intégrité dans une section de fin est qu'elle permet le hachage des octets au fur et à mesure de leur envoi. Cependant, il est possible de concevoir un algorithme de hachage qui nécessite le traitement du contenu de telle manière que ces avantages seraient annulés. Par exemple, l'encodage de contenu d'intégrité Merkle [MICE] nécessite que le contenu soit traité dans l'ordre inverse. Cela signifie que les données complètes doivent être disponibles, ce qui signifie qu'il y a une différence de traitement négligeable entre l'envoi d'un champ d'intégrité dans un en-tête et dans une section de fin.

6.5. Variations au sein de Content-Encoding

Les mécanismes de codage de contenu peuvent prendre en charge différents paramètres d'encodage, ce qui signifie que le même contenu d'entrée peut produire des sorties différentes. Par exemple, GZIP prend en charge plusieurs niveaux de compression. De tels paramètres d'encodage ne sont généralement pas communiqués en tant que métadonnées de représentation. Par exemple, différents niveaux de compression utiliseraient tous le même champ "Content-Encoding: gzip". D'autres exemples incluent le cas où l'encodage repose sur des nonces ou des horodatages, tels que le codage de contenu aes128gcm défini dans la [RFC8188].

Puisqu'il est possible qu'il y ait des variations au sein du codage de contenu, la somme de contrôle transmise par les champs d'intégrité ne peut pas être utilisée pour fournir une preuve d'intégrité "au repos" à moins que tout le contenu ne soit conservé.

6.6. Agilité de l'algorithme

Les propriétés de sécurité des algorithmes de hachage ne sont pas fixes. L'agilité de l'algorithme (voir la [RFC7696]) est obtenue en offrant aux implémentations la flexibilité de choisir des algorithmes de hachage dans le registre IANA Hash Algorithms for HTTP Digest Fields ; voir la section 7.2.

La transition à partir d'algorithmes faibles est prise en charge par la négociation de l'algorithme de hachage à l'aide de Want-Content-Digest ou Want-Repr-Digest (voir la section 4) ou par l'envoi de plusieurs condensats parmi lesquels le récepteur choisit. Un récepteur qui dépend d'un condensat pour la sécurité sera vulnérable aux attaques sur l'algorithme le plus faible qu'il est prêt à accepter. Les points de terminaison sont informés que l'envoi de plusieurs valeurs consomme des ressources qui peuvent être gaspillées si le récepteur les ignore (voir la section 3).

Bien que l'agilité de l'algorithme permette la migration vers des algorithmes plus forts, elle n'empêche pas l'utilisation d'algorithmes plus faibles. Les champs d'intégrité ne fournissent aucune atténuation pour les attaques de rétrogradation ou de substitution (voir la section 1 de la [RFC6211]) de l'algorithme de hachage. Pour se protéger contre de telles attaques, les points de terminaison pourraient restreindre leur ensemble d'algorithmes pris en charge à des algorithmes plus forts et protéger les valeurs des champs en utilisant TLS et/ou des signatures numériques.

6.7. Épuisement des ressources

La validation des champs d'intégrité consomme des ressources de calcul. Afin d'éviter l'épuisement des ressources, les implémentations peuvent restreindre la validation des types d'algorithmes, le nombre de validations ou la taille du contenu. Dans ces cas, sauter entièrement la validation ou ignorer l'échec de validation d'un algorithme plus préféré laisse la possibilité d'une attaque de rétrogradation (voir la section 6.6).