HTTP Message Signatures：经过代理转发后，怎样验证请求没被改？
TL;DR
HTTP 消息签名可对选定方法、URI 和头部等组件建立跨连接的完整性证据。本文说明签名覆盖范围、正文摘要、密钥信任和防重放设计，避免把它误认为自动加密整份 HTTP 请求。
HTTP 消息签名可对选定方法、URI 和头部等组件建立跨连接的完整性证据。本文说明签名覆盖范围、正文摘要、密钥信任和防重放设计，避免把它误认为自动加密整份 HTTP 请求。
HTTPS 能保护浏览器与某个服务器之间的连接，但请求经过代理、网关或消息队列后，原始 TLS 连接可能早已结束。下游系统怎样确认请求中的关键字段确实来自上游、而且在转发过程中没有被改动？HTTP Message Signatures（HTTP 消息签名）让发送方可以对选定的 HTTP 组件计算数字签名或消息认证码。
与“把整个 HTTP 报文原样签名”不同，这套机制会根据规范定义的规则构造待签名内容：例如方法、目标 URI、特定头部、时间戳或请求标识。签名随消息传递，接收方按相同规则重建签名输入，再使用共享密钥或公钥验证。这样即使请求跨越多个 TLS 连接，最终系统仍可核对被选择字段是否保持一致。
“被选择”是最重要的限制。签名只覆盖发送方明确纳入签名基底（signature base）的组件；未包含的头部或字段可以被中间节点修改，而验证仍通过。更容易忽略的是，请求正文通常不会因为签了几个头部就自动受到保护。若要保证正文完整性，设计通常还要先计算内容摘要，并把摘要字段纳入签名。
签名机制也不替应用决定信任谁。系统要配置密钥身份、算法、有效期、可接受的签名覆盖范围以及失败处理方式。若验证方拿错了公钥，或允许过宽的算法集合，签名可能失去意义；如果请求被原样重放，单纯的签名仍可能有效，因此时间戳、随机数、请求 ID 和业务幂等策略常用于防重放。
可以把它想成给一份公文盖骑缝章：章能证明指定页和指定字段未被替换，但如果没有把附件清单也纳入验证，附件依然可能被调包。HTTP 消息签名的强项是跨连接、跨代理保留端到端的完整性证据；它不会自动加密内容，也不会自动证明业务请求合理。
在微服务、支付请求、Webhook 或代理链路中，消息签名可让接收方不必完全依赖最近一跳的 TLS 连接，而是验证更早的发送方声明。落地时应先明确“哪些部分必须防改”，再写出稳定、最小但充分的签名配置，并用篡改、过期和重放测试验证整个链路。
