7.2.8. Contenu du message

7.2.8. Contenu du message

En elle-même, cette spécification ne couvre pas le contenu d’un message HTTP sous la signature, que ce soit dans une requête ou une réponse. Toutefois, [DIGEST] définit un ensemble de champs permettant de représenter dans un champ un condensat cryptographique du contenu. Une fois ce champ créé, il peut être inclus comme tout autre champ, tel que défini à la section 2.1.

Par exemple, dans le message de réponse suivant :

HTTP/1.1 200 OK Content-Type: application/json

{"hello": "world"}

Le condensat du contenu peut être ajouté au champ Content-Digest comme suit :

NOTE : retour à la ligne avec '' selon la RFC 8792

HTTP/1.1 200 OK Content-Type: application/json Content-Digest:
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

{"hello": "world"}

Ce champ peut être inclus dans une base de signature comme tout autre champ, avec les paramètres de signature de base :

"@status": 200 "content-digest":
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=: "@signature-input": ("@status" "content-digest")

À partir de là, le processus de signature se poursuit comme d’habitude.

Lors de la vérification, il importe que le vérificateur valide non seulement la signature, mais aussi la valeur du champ Content-Digest par rapport au contenu réellement reçu. Sans cette étape, un attaquant pourrait substituer le contenu du message tout en laissant la valeur du champ Content-Digest inchangée pour faire passer la signature. Comme seule la valeur du champ est couverte directement par la signature, vérifier uniquement la signature ne suffit pas à se protéger contre une telle attaque par substitution.

Comme indiqué dans [DIGEST], la valeur du champ Content-Digest dépend du codage du contenu du message. Si un intermédiaire modifie le codage du contenu, la valeur Content-Digest résultante change. La signature serait alors invalidée. Tout intermédiaire effectuant une telle action devrait appliquer une nouvelle signature avec la valeur de champ Content-Digest mise à jour, comme dans le cas d’usage du proxy inverse décrit à la section 4.3.

Les applications qui utilisent le paramètre req (section 2.4) doivent aussi connaître les limites de cette fonctionnalité. En particulier, si un client n’inclut pas quelque chose comme un champ d’en-tête Content-Digest dans la requête, le serveur ne peut pas inclure une signature couvrant le contenu de la requête.