Résumé

  • Content-Digest contrôle le contenu effectivement transporté ; Repr-Digest contrôle les données de la représentation sélectionnée. Aucun des deux n'authentifie celui qui a choisi ces octets.
  • Une preuve exploitable sépare le domaine d'octets, l'algorithme, le recalcul, la signature, l'autorité de la clé, la fraîcheur, le rejeu, la validation métier et l'action finale.

Une vérité trop petite pour la décision

Le voyant vert ne mentait pas : la valeur recalculée correspondait à celle du champ. L'erreur venait du verbe sous-entendu. Les octets avaient été contrôlés, pas l'auteur de la requête, son mandat ni l'effet acceptable du document.

Une fonction de hachage robuste empêche certaines substitutions lorsqu'une valeur de référence digne de confiance existe. Elle ne crée pas cette référence. Celui qui peut fournir simultanément le corps et son empreinte n'a aucun obstacle cryptographique à franchir. Il calcule simplement l'empreinte de son propre corps.

Il faut donc bannir le statut générique verified. Le système doit écrire content_digest_matched, signature_verified, key_authorized ou replay_rejected. Le nom du prédicat fixe la limite de la preuve.

Le contenu n'est pas toujours la représentation

RFC 9530 a remplacé l'ancien champ Digest par deux objets explicites. Content-Digest porte sur le contenu du message HTTP. Repr-Digest porte sur l'ensemble des données de la représentation sélectionnée.

La différence devient concrète avec la compression, les réponses partielles, HEAD ou PATCH. Un intermédiaire peut vérifier les octets compressés qu'il reçoit tandis que l'application raisonne sur une représentation décodée. Les deux calculs peuvent être justes et néanmoins ne pas protéger le même invariant.

Avant de sélectionner SHA-256 ou SHA-512, l'équipe doit donc sélectionner l'objet. Quel flux d'octets doit rester identique ? À quel moment de l'encodage, du décodage ou de la reconstruction ? L'abandon de RFC 3230 est instructif : la notion d'« instance » avait été comprise de façon divergente, notamment entre contenu du message et représentation.

Une syntaxe correcte n'accorde rien

Les champs sont des dictionnaires Structured Fields. Chaque clé désigne un algorithme et chaque valeur contient une séquence d'octets encodée. Plusieurs algorithmes peuvent coexister pour faciliter une transition.

Le parseur ne décide pourtant ni de la robustesse ni de l'admissibilité. Le registre IANA indique l'état des algorithmes ; l'application doit encore maintenir sa propre liste d'acceptation. RFC 9530 recommande les algorithmes actifs pour de nombreux usages et interdit les algorithmes dépréciés dans une situation potentiellement hostile.

Le Base64 n'est qu'un encodage. Le hachage calcule une empreinte. La signature lie des composants choisis à une clé. Confondre ces opérations revient à attribuer une autorité cryptographique à de la ponctuation.

Les champs Want-Content-Digest et Want-Repr-Digest n'imposent pas davantage une politique. Ce sont des préférences indicatives que le destinataire peut ignorer. Une application qui exige une empreinte doit formaliser son obligation et son comportement d'échec.

La signature exige encore le recalcul

Les signatures de messages HTTP peuvent couvrir Content-Digest, la méthode, la cible et d'autres composants choisis. Couvrir le champ est utile : sa valeur déclarée est alors liée à une clé vérifiée.

Mais une signature valide du champ ne compare pas automatiquement le corps reçu à cette valeur. Si un défaut remplace le corps sans toucher au champ signé, la signature peut rester valide. Le destinataire doit recalculer séparément le condensé du contenu et le comparer.

L'inverse échoue aussi. Un condensé recalculé sans vérification de signature accepte le corps et le condensé fournis ensemble par n'importe qui. Puis, même après une signature valide, l'application doit vérifier que la clé est autorisée pour l'action, que les composants indispensables sont couverts, que les paramètres temporels sont acceptables et que la requête n'est pas rejouée.

Authenticité et autorisation ne sont pas synonymes. Une clé connue peut signer une opération qu'elle n'a pas le droit d'ordonner.

La bande-annonce déplace le moment de vérité

RFC 9530 permet de placer le champ en en-tête ou en bande-annonce. La seconde option convient à un flux dont l'empreinte n'est connue qu'après émission du corps. Elle oblige aussi le récepteur à attendre la fin.

Si l'application modifie l'état pendant la lecture puis examine la bande-annonce, l'échec arrive trop tard. Il faut mettre en attente, travailler dans une transaction réversible ou différer l'action jusqu'au contrôle complet.

HTTP/1.1, HTTP/2 et HTTP/3 ne transportent pas les bandes-annonces de manière identique. Proxy, bibliothèque et cadre applicatif peuvent les supprimer ou les exposer différemment. Seul un essai traversant le chemin de production démontre que le champ atteint le décideur avant l'engagement.

Les octets intacts peuvent être périmés

Une réponse conservée en cache peut avoir exactement les mêmes octets qu'hier et une empreinte parfaite. RFC 9111 confie pourtant la fraîcheur et la revalidation aux règles de cache. Le condensé ne rajeunit pas une réponse.

De même, une requête signée capturée peut être rejouée avec un corps, un condensé et une signature tous intacts. Les fenêtres temporelles, nonces, identifiants de requête et règles d'idempotence décident si la seconde exécution est permise.

Enfin, l'intégrité ne juge pas le sens. Un fichier conforme à son schéma peut ouvrir un accès administrateur dangereux. Une archive peut correspondre à l'empreinte annoncée par son éditeur et contenir une vulnérabilité. La preuve conserve l'objet présenté ; elle ne valide pas son effet.

L'essai qui révèle le modèle d'autorité

Le premier test doit envoyer un contenu malveillant avec son condensé exact. Le contrôle d'intégrité doit réussir et l'autorisation doit échouer. Puis il faut modifier un octet, conserver le condensé et exiger un rejet avant toute action.

Il faut signer une requête qui omet Content-Digest, puis une autre qui couvre le champ mais dont le corps est modifié. Ces deux expériences rendent visibles la sélection des composants et la nécessité du recalcul. Ajoutez plusieurs algorithmes, dont un déprécié, et vérifiez que l'ordre ne provoque aucun abaissement de sécurité.

Enfin, faites passer en-têtes et bandes-annonces par chaque version HTTP, chaque proxy, la compression, une plage partielle et le cache. Rejouez une requête valide. Le résultat attendu n'est pas un badge unique, mais une suite de décisions nommées dont chacune reste dans son domaine.