跳到主要内容

7.2.8. Message Content (消息内容)

7.2.8. Message Content (消息内容)​

本规范自身不为请求或响应中的 HTTP 消息内容提供签名覆盖. 然而, [DIGEST] 定义了一组允许在字段中表示内容密码学摘要的字段. 创建该字段后, 可按第 2.1 节像任何其他字段一样纳入.

例如下列响应消息:

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

{"hello": "world"}

内容摘要可按如下加入 Content-Digest 字段:

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

{"hello": "world"}

该字段可与基本签名参数一起像任何其他字段一样纳入签名基:

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

此后签名过程照常进行.

验证时, 验证者必须不仅验证签名, 还要将 Content-Digest 字段的值相对实际收到的内容验证. 除非验证者执行此步骤, 攻击者可能替换消息内容但保留 Content-Digest 字段值不变以通过签名. 由于仅字段值直接被签名覆盖, 仅检查签名不足以防护此类替换攻击.

如 [DIGEST] 讨论, Content-Digest 字段的值取决于消息的内容编码 (content encoding). 若中间人改变内容编码, 所得 Content-Digest 值会改变, 进而使签名无效. 执行此类操作的任何中间人需要应用带更新 Content-Digest 字段值的新签名, 类似第 4.3 节讨论的反向代理用例.

使用 req 参数 (第 2.4 节) 的应用还需了解此功能的限制. 具体地, 若客户端未在请求中包含类似 Content-Digest 头字段的内容, 服务器无法在签名中包含请求内容的覆盖.

7.3. Cryptographic Considerations (密码学注意事项)​

最后于 更新