摘要

  • draft-ietf-httpapi-privacy-06 的核心时间边界在 3xx 之前：服务器还来不及响应时，认证客户端就可能已经把可复用秘密送上明文链路。
  • HSTS、DNS HTTPS 记录、关闭 80 端口、凭据的安全上下文限制和客户端 HTTPS-only 默认值分别作用于不同阶段；最终 URL 不能替代任何一项。
  • 明文收到凭据后，服务器还要统一拒绝、判断暴露类型并决定吊销。该草案已获 IESG 批准并进入 RFC Editor Queue，但截至 2026 年 10 月 1 日仍不是正式 RFC。

安全事故不一定以失败出现。最难发现的一类事故，会先泄露秘密，再把业务请求做成。

配置文件把 API 基址写成 HTTP 形式，而不是 HTTPS 形式。运行库组装请求时照常加入认证头，连接建立后把整条请求发出。服务器回一个重定向，客户端自动跟随，第二次连接使用 TLS，业务返回 200。监控只看到最终成功，凭据却已经在第一次传输中暴露。

《Protecting Credentials with HTTP APIs》06 版要求从网络真实顺序出发。重定向是一条响应；要产生响应，先得有请求到达某个接收者。后来的加密只能保护后来发生的交换，不能把早先经过网络的字节收回来。

成功路径为何比报错更危险

面向人的网页会用 HTTP 到 HTTPS 的跳转纠正裸域名输入，这是可理解的体验设计。认证 API 的条件不同：软件已经拥有完整 URI 和可执行权限，不需要用“自动原谅”换便利。若错误立即失败，开发者会修正配置；若跳转成功，错误可能随部署长期存在。

推动这份草案的2024 年 5 月实测文章正是从一次 http 拼写错误出发，并列出当时的若干服务表现。那是一份历史快照，不是 2026 年供应商现状清单；部分服务后来改变了策略，示例凭据也不能证明所有认证路径。但它所揭示的机制不依赖名单：调用成功会掩盖首次传输的不安全。

必须按阶段留证。配置 URI 只能证明输入；DNS 和 HTTPS RR 证明发现结果；HSTS 状态证明客户端是否保存过先前政策；第一条线上请求证明凭据是否进入明文；3xx 或 403 证明响应；第二次 TLS 握手证明新的安全连接；吊销记录证明暴露凭据如何处置；授权与提交记录才说明业务效果。把这些合成一个“安全成功”状态，等于删除事故发生的时间轴。

真正有效的控制都在首包之前

RFC 6797定义的 HSTS 能让客户端未来只使用安全传输，但它通常要通过一次成功 HTTPS 连接学习，并依赖持久保存。服务器发送过 HSTS 头，不代表某个命令行 SDK 就实现了相同的状态机。

RFC 9460的 HTTPS 资源记录把信号前移到连接选择阶段。客户端仍需发起查询、正确解释，并面对新客户端上 DNS 信息可能被压制的问题。草案建议认证 API 同时部署 HSTS 与 HTTPS 记录，表达的是防线叠加，而不是任何一项单独构成绝对保证。

服务器不监听明文端口，可以阻止凭据抵达真实服务器。这是重要的最小化措施，却不能抵御主动冒充：攻击者可以在网络上代替那个没有回应的 HTTP 端点。最终的安全不变量仍必须由客户端执行——在安全传输确定以前，不附加秘密。

凭据本身也能带约束。RFC 6265的 Secure 属性禁止 Cookie 通过不安全通道发送；RFC 8959定义的 secret-token URI 可传达预期用法。自定义 X-Api-Key 头不会因为名字像秘密就自动获得这套执行规则。安全意图只有落实到客户端代码才是控制。

403 只是事故入口

如果共享主机等原因要求保留 80 端口，06 版建议：凡是不安全连接中出现任何凭据，一律返回 403，不因凭据真假改变客户端可见结果。RFC 9110允许服务器出于与凭据是否充分无关的理由拒绝请求。若真实密钥与错误密钥得到不同状态、正文或时延，端点就会变成凭据探测器。

统一拒绝防止第二层泄露，却无法撤销第一层泄露。直接传输的 API key 或 bearer token 可以被旁观者复制使用，应视为可能失陷。数字签名或 MAC 是秘密的派生结果，未必暴露秘密本身；此时应另查消息覆盖、nonce、请求绑定与重放属性。不能只依据“认证请求”四个字统一吊销。

吊销本身也是权力。攻击者可能在 HTTP 上批量提交猜测值，试图碰中并吊销有效凭据。连接限制、速率限制、通知、隔离与受控宽限期都要进入运行政策。防止吊销型拒绝服务，并不等于允许系统继续相信已经明文出现的 bearer 凭据。

已获批准不等于已经部署

Datatracker把该文件列为 HTTPAPI 工作组的 Best Current Practice 候选。文档历史显示，IESG 于 2026 年 6 月 5 日批准并将其送入 RFC Editor Queue。到 10 月 1 日，公开文本仍是 5 月 11 日的 06 版，没有 RFC 编号。

这条程序轨迹证明它接受过工作组、HTTP 与安全审查，不证明任何具体库遵守建议。 shepherd 材料还明确说明没有提交特定实现报告。工作仓库能证明文本如何演进，不能替代某一 SDK 冷启动时的网络抓包。

RFC 7258把普遍监控视为攻击，也说明 HTTPS 不只是“包住密钥”的工具。即使没有凭据，请求路径、标识符与行动意图也可能敏感；可复用 token 只是把观察立即升级为可被盗用的权限。

按线上顺序记账

为每种客户端记录：精确 base URI、库与版本、重定向策略、何时附加凭据、独立的不安全模式开关、DNS 与 HTTPS RR 结果、HSTS 状态来源及年龄、第一条真实连接的 scheme/地址/端口/对端、凭据类别但不记录秘密值、首个响应和 Location、第二条 TLS 连接的认证对端、暴露等级、隔离/轮换/吊销及传播状态、资源授权、提交 ID 和外部观测结果。

未知不得改写为安全。没有 HSTS 存储就写 none；DNS 信号缺失就写 unavailable_or_suppressed；明文请求可能携密就写 exposure=possible；吊销尚未全局生效就写 pending。最终 HTTPS span 不得覆盖最初 HTTP span。

Lu Heng 的最小初始规范在这里对应一条极薄的共同规则：可复用秘密不得进入不安全传输，其他凭据与吊销政策保留本地决定。运行代码优先要求观察真实首包。政策之镜揭示 SDK 默认值和网关监听器才是权限分配者。现实分层让配置、发现、传输、暴露、响应、授权和效果各自保留证据。

来源