curl 8.22 新增 HTTP 消息签名：采用前先测试代理链路
curl 8.22.0 于 2026 年 9 月 2 日发布，新增对 RFC 9421 HTTP Message Signatures 的实验性支持。命令行客户端可以用 Ed25519 或 HMAC-SHA256 为选定请求组件签名，libcurl 也提供对应的认证与签名选项。
这项能力可以让接收方验证 HTTP 请求中的特定属性，但不会自动让代理线路变得可信。curl 官方文档明确标记该功能为实验性，并警告不要用于生产环境。把 curl 与正向代理、安全隧道、地区出口、重试或重定向结合的团队，应先确认“签署的请求”与“验证端收到的请求”是否一致。
curl 8.22 增加了什么
新命令行选项覆盖四类输入：
- 签名算法；
- 签名密钥或密钥文件；
- 供验证端查找密钥的标识；
- 纳入签名的派生组件与请求头。
若未指定组件列表，curl 默认签署 method、authority、path，并在存在查询字符串时签署 query。自定义列表可以包含派生组件和显式设置的请求头。官方文档还说明，请求头组件来自命令行显式提供的请求头；curl 自动添加的请求头即使出现在网络上，也不会因此自动进入签名。
因此，如果应用希望保护 user agent、content type 或 content digest，就应明确设置并选择对应组件，再确认验证端使用同一种解释方式。
为什么代理链路必须单独验证
HTTP 消息签名只保护签名者选定的组件。它不会加密请求、授予数据使用权，也不会证明所有中间节点都按预期工作。
通过常规 CONNECT 隧道访问 HTTPS 目标时，隧道建立后的源站请求通常位于端到端 TLS 内。代理负责认证和转发隧道，消息签名由目标端验证。
其他架构可能终止、重建或改写 HTTP。显式 HTTP 代理、反向代理、服务网关、重定向处理器或应用中间件，可能改变 authority、请求目标、路径规范化、查询顺序或已签名请求头。即使改写有正当理由，只要验证端看到的签名材料不同，验证就会失败。
不要一开始就断言“代理破坏了签名”。应在受控边界采集脱敏证据，找出第一个发生差异的组件。
建立六条链路兼容矩阵
| 链路 | 需要回答的问题 |
|---|---|
| 直连 HTTPS | 验证端能否通过基准请求？ |
| HTTPS 经 CONNECT | 源站收到的签名组件是否相同？ |
| 明文 HTTP 经显式代理 | authority 与请求目标如何表示？ |
| 经代理发生重定向 | 是否创建新请求，是否按预期重新签名？ |
| 请求重试 | 请求体、摘要、时间与请求头是否一致？ |
| 地区或故障转移网关 | 路由选择是否改变 authority、path、query 或请求头？ |
只使用自有或明确获准测试的端点。验证端应返回有限结果，例如有效、无效、缺少组件、未知密钥标识或算法不支持，不能返回秘密材料。
安全运行命令行实验
生成非生产测试密钥，并让它远离命令历史、日志和共享制品。随后向受控验证端发送签名请求：
curl --httpsig-algo ed25519 \
--httpsig-key @test-key.hex \
--httpsig-keyid test-key-01 \
--httpsig-headers "method authority path query content-type:" \
-H "Content-Type: application/json" \
--data '{"probe":"proxy-path"}' \
"$AUTHORIZED_VERIFIER_URL"该环境变量只能设置为已获授权的验证端。不要把生产密钥直接写入可能被保存的命令。
让同一逻辑请求依次经过各条获准代理线路。记录 curl 版本、代理类型、地址族、请求地区、重定向策略、签名组件、验证结果和请求体哈希。代理凭据、Cookie、签名值与密钥材料必须脱敏。
逐一检查组件边界
Authority
确认验证端使用的 authority 与签名者目标一致。默认端口、显式端口、别名和网关应分别测试。不能为了“修复”偏差而信任任意主机。
Path 与 query
检查百分号编码、重复查询字段、空值、参数顺序、尾部斜杠和路径规范化。多种库共同生成 URL 时，语义相近的请求仍可能有不同字节表示。
显式请求头
只选择在预期链路中稳定的请求头。如果追踪头应由网关添加，不要签署一个客户端不存在的值，再假设中间节点可以修复。
请求体与内容摘要
如果应用保护 content digest，应一致地计算并设置它。检查压缩、序列化、传输编码和重试逻辑会不会重建不同请求体。
把重定向和重试视为新安全事件
重定向可能改变 authority、path、query、方法或请求体行为；重试可能发生在部分发送之后，也可能遇到凭据或时间信息过期。不要把旧签名自动复制到新构造的请求。
每类重定向与重试都应规定：
- 客户端是否允许跟随；
- 新目标是否仍在授权范围；
- 哪些组件必须重新生成；
- 请求体能否安全重放；
- 最大尝试次数与总时间预算；
- 哪种结果必须停止任务。
可以结合代理重试预算指南，防止确定性的签名失败触发无控制出口轮换。
将密钥与遥测分离
可观测数据应帮助定位组件差异，但不能泄露秘密。可记录 curl 构建版本、算法名称、密钥标识、组件名称、验证结果、请求关联编号、线路类别和脱敏错误原因。不要记录私钥、共享 HMAC 秘密、完整签名请求头、有效代理凭据或敏感请求体。
测试密钥应有有限权限和明确停用日期，并按环境与所有者隔离。HMAC 秘密由签名端与验证端共同持有；Ed25519 则允许验证端只保存公钥。
代理团队升级清单
- 确认运行环境为 curl 或 libcurl 8.22.0 以上。
- 明确记录 HTTP 消息签名仍是实验功能。
- 建立受控验证端和非生产密钥。
- 定义真正需要保护的组件。
- 重要请求头必须先显式设置再纳入签名。
- 建立直连 HTTPS 基准。
- 按需测试 CONNECT、显式代理、重定向、重试、IPv4、IPv6 和地区线路。
- 比对 authority、path、query、请求头、请求体摘要与验证结果。
- 限制重试；确定性签名失败不得触发自动轮换。
- 脱敏密钥、签名、凭据、Cookie 与敏感请求体。
- 先通过有限金丝雀启用。
- 任何生产决定前重新核对 curl 文档。
一般发布流程可以参考代理试用验收测试和代理直连回退检测指南。
常见问题
HTTP 消息签名会加密请求吗？
不会。它帮助验证选定组件。机密性和服务器认证仍依赖 TLS，访问授权也必须单独处理。
CONNECT 代理一定会让签名失效吗？
不会。典型 HTTPS CONNECT 隧道中的源站请求位于 TLS 内，但网关、重定向和中间件可能产生不同结果，因此必须测试实际实现。
为什么请求头已经上网，却没有被签名？
curl 的实验性命令行功能对显式提供并显式选择的请求头签名。自动生成的请求头不一定在签名输入中。
是否应立即在生产环境启用？
不应。curl 将这些选项标记为实验性，并警告不要用于生产。先在隔离环境评估，并继续关注后续版本说明。
合规说明
签名请求与代理只能用于已获授权的系统、账号、数据和地区。签名证明选定请求属性，不会授予权限、绕过速率限制或支持规避访问控制。保护密钥与个人数据，遵守目标条款和服务商政策，遇到授权或策略失败时停止。
来源说明：curl 项目《Changes in 8.22.0》及 curl 8.22.0 命令行手册，发布于 2026 年 9 月 2 日。依据 98IP 零外链规则，资料地址仅保存在内部运营记录。
