摘要

  • RFC 9729 让已配置密钥的客户端在第一次请求中提交证明，服务器无需用 401 挑战暴露“这里存在受保护能力”。
  • 证明绑定的是 TLS 连接和源站上下文，并不绑定具体方法、路径或消息体；TLS 终止点、连接复用和前后端转发因此成为认证边界的一部分。
  • 对外统一成“不存在”不能成为对内失忆。部署方必须保留受控的失败原因、配置代次、连接来源、撤销状态和最终资源效果。

设想一条敏感运维路径。陌生访问者得到普通的 404；持有正确密钥的客户端则在同一个 URL 上获得服务。服务器没有先说“请认证”，客户端也没有从挑战中学到资源存在。证明必须在服务器开口之前完成。

RFC 9729 把这种机制命名为 Concealed。它不是把认证藏进一个秘密 URL，而是用 TLS 导出器提供新鲜性，让客户端主动发送非对称签名。传统挑战所承担的随机量由连接产生；挑战泄露的存在信号随之消失。但能决定谁有资格、哪个源站接受哪把钥匙、哪个代理可以代表 TLS 连接说话的权力仍然存在。

第一条边界在 HTTP 之外

标准假定密钥通过外部机制分发。客户端掌握密钥标识和非对称密钥对，源站保存被接受的标识到公钥映射。至于成员资格由谁批准、私钥怎样进入设备、离职与遗失如何处理、数据库何时完成撤销传播，协议没有替组织作决定。

因此，签名正确只说明“这把私钥参与了计算”。如果接受表已经过期，密码学会非常精确地证明一项过期政策。删除客户端文件也不是撤销；只有每个可能响应该资源的验证器都加载了新代次，并且合成请求证明旧钥匙已经失败，撤销才从行政动作变成运行事实。

运营清单至少要把签发者、主体类别、允许的源站与 realm、公钥指纹、启用和失效时间、撤销状态、策略代次以及所有验证节点串成关系。私钥不应进入日志，但控制证据必须能回答：哪一代政策在何处生效，谁能证明它生效。

TLS 导出器究竟绑定了什么

客户端使用注册标签 EXPORTER-HTTP-Concealed-Authentication。导出器上下文包含 TLS 签名算法编号、密钥标识、公钥、URI scheme、主机、端口和可选 realm，输出 48 字节：其中 32 字节进入签名输入，16 字节作为 v 参数发送。

认证字段还携带 k、a、p 和 s。服务端既比较提交公钥与本地映射，也比较 v 与本连接的导出结果，再验证签名。这样做是在抵抗密钥混淆，并确保签名属于当前连接上下文。

这组上下文有一个重要的缺口：它没有绑定 HTTP 方法、路径和消息体。同一把钥匙在同一条连接上可对多个请求产生相同证明，有利于头部压缩，却也意味着能读取另一个隔离域 Authorization 字段的上下文可能在该连接上重放它。HTTP/2、HTTP/3、浏览器会话或代理租户的复用隔离，不再只是性能实现细节。

“新鲜”同样不能只写成一个布尔值。证明最多与底层连接一样新；长连接或恢复连接会让认证上下文比一次登录的直觉寿命更长。需要更短窗口时，服务器可要求重建连接，但这会影响延迟、容量和故障模式。连接年龄、恢复谱系、强制轮换原因和策略代次应与认证结论一起记录。

TLS 终止点获得了主体权力

单进程部署可以把导出器字节交给同一应用的验证函数。分离部署则由 TLS 前端把原 Authorization 字段和新的 Concealed-Auth-Export 字段发送给后端。后端无法用自己到前端的连接重算客户端到前端的导出材料，只能相信前端的断言。

标准由此给出两条硬规则：后端仅在已经信任发送方时使用该字段；前端不能转发客户端自己注入的同名字段。负载均衡器因此不再只是“传输设施”。它能够制造应用接受身份所依赖的通道绑定材料。

共享网段或宽泛 ACL 不足以表达这种信任。证据应包括经过认证的前端身份、软件与配置代次、面向客户端的连接标识、虚拟主机、规范化 authority、受保护的导出器关联值和最终后端路由。若服务网格丢失原认证字段、重复导出字段、以不同 host 构造上下文，或验证后又路由到另一权威域，客户端可能只看到一个完美统一的 404。隐蔽没有限制故障，只限制了症状。

认证成功不是资源授权

后端要完成一组独立检查：解析所需参数、找到密钥标识、核对公钥、核对导出验证值、验证签名。任何一步失败都按未提供凭证处理。全部通过后，后端才可以把请求视为已认证。

这并不意味着请求已获授权。承包商的有效钥匙可能只能访问一个能力；账户可能暂停；后端可能仍运行旧的授权表；路由也可能在完全未执行 Concealed 验证时意外开放资源。日志中必须把认证结论、授权策略和资源效果分开，否则“签名有效”会掩盖系统性拒绝，“404 一致”也会掩盖绕过认证的公开路径。

统一失败是一项披露政策

对不可探测资源，认证失败必须得到与不存在资源完全相同的响应。状态码只是第一维；正文、头字段、缓存行为、连接处理、长度和延迟都可能分叉。不存在路径立即返回，而受保护路径执行查表和签名验证，就会留下定时预言机。

测试不能靠两次秒表读数。它要在相似负载和网络条件下比较响应分布，也要检查索引、站点地图、错误信息、客户端包、文档、分析事件和 DNS 名称等旁路。Concealed 只消除一个 HTTP 挑战信号，不会自动撤销其他发布决定。

标准文本也要纳入版本证据

RFC 9729 勘误记录已经展示了复制示例的风险。已确认的勘误 8807 指出，十六进制示例编码成了 HTTP Signature Authentication，而规范构造写的是 HTTP Concealed Authentication。依赖示例而非命名上下文的实现，会把互操作失败藏在刻意模糊的外部响应后面。

另一项仍处于 reported 状态的勘误 8843 涉及 s 参数的整数 ABNF：印刷表达式排除了非零一位数，正文却允许 0 到 65535。运营方应记录采用的解析规则、测试实际部署版本，并持续跟踪勘误状态，而不是把标准歧义归类为“坏凭证”。

IANA 对认证 scheme、导出器标签和 Concealed-Auth-Export 字段的登记证明了名称和引用得到协调。登记不能证明客户端支持、密钥签发、代理配置、路由覆盖或响应一致性。文档层权威与运行层效果必须分开取证。

对外模糊，对内精确

合理架构故意维护两个不同界面。公开界面减少未授权者可观察的区别；私有界面向有责任且受审计的运营人员保留结构化原因：格式错误、未知或已撤销密钥、公钥不符、导出值不符、签名无效、TLS 条件不合格、前端不可信、授权拒绝、路由错误和下游故障。

这些原因不能回流到公开正文或延迟。它们应通过受保护关联标识连接到配置与连接事实，有明确保存期限和访问审计。最佳负向对照是普通的“不存在”：测试集同时放入未配置路径、无凭证的隐蔽路径、畸形凭证、未知与撤销钥匙、错误 host/port、无资格 TLS、客户端注入导出字段、不可信前端以及认证成功后的授权拒绝。对外观察按政策趋同，对内诊断必须保持不同。

来源