摘要

  • RFC 9540 在 SVCB 或 HTTPS 记录中定义空值 ohttp 参数，并把客户端引向同一主机上的 /.well-known/ohttp-gateway，再获取网关密钥配置。
  • 这套发现机制不负责发现或认证中继；DNS 宣告、证书有效、密钥可用和请求完成，分别只能证明各自那一步。
  • 网关或解析器可以向单个客户端下发独有的密钥配置、重定向或 dohpath，所以“是否与他人一致”必须有独立凭证。

事故没有表现为失败。两台终端都发现了同一个 OHTTP 服务，都通过了证书检查，都从网关拿到了合法密钥，也都经由中继收到了 DNS 响应。仪表板于是把两条链路标成绿色。

差异藏在成功之中：第一台终端使用的是全网常见的密钥配置；第二台终端拿到的配置从未在其他观测点出现过。加密没有被攻破，客户端却已经被划进了一个只有自己的群组。

RFC 9540 于 2024 年 2 月发布，它的价值不只是把 Oblivious HTTP 服务发现标准化。它还明确写出了发现链如何反过来成为定向识别面。对管理者而言，关键不是给产品贴上“支持 OHTTP”的标签，而是把宣告、指定、验证、一致性、中继和最终隐私效果拆成不同责任。

一个空参数也能改变控制权

ohttp SvcParamKey 的展示值和线上值都必须为空。它不携带地址或密钥，仅以“存在”表示该 SVCB 或 HTTPS 记录描述的服务可以作为 OHTTP 目标，并有相关网关可供访问。

空值并不意味着无决策。如果 ohttp 被列入 mandatory，不理解这个参数的客户端必须忽略该记录；如果未列入，它只是可选访问方式。发布者还可以放出多条记录，呈现不同配置。这个小小的标记因此可以决定客户端是否接受某条服务路径。

但其凭证范围必须被锁住：某个 DNS 权威在某个时间、TTL 和选择规则下宣告了能力。它没有证明客户端最终使用 OHTTP，没有证明网关可达或可信，更没有证明其他客户端看到了相同配置。若查询通过未受 DNSSEC 保护的明文 DNS，路径上的攻击者可以删除 SVCB 信息，制造降级。主动检查 well-known 路径，或把加密 DNS 与 DNSSEC 配合使用，可以降低风险，却仍然不能替网关后续行为作证。

RFC 9540 发现网关，却没有替你选择中继

OHTTP 把可见信息分给三个角色。中继看到客户端网络身份和网关目的地，但看不到封装内容；网关解开 OHTTP 消息，却不应从一次交易中直接获得客户端身份；目标服务完成应用处理。

RFC 9540 处理目标与网关的发现，明确把中继发现排除在范围之外。其部署模型假定客户端已经配置了可信中继，而且中继能够访问一般网关，或能帮助客户端判断哪些网关可达。

这不是可以藏在实现细节里的假设。谁选择中继？它保留哪些日志？处于什么司法管辖区？它是否与网关共享运营者、云平台或商业激励？当滥用调查要求保留更多记录时，谁来批准？完整实现 RFC 9540 也无法自动回答这些问题。“已发现 OHTTP”不能覆盖一个尚未解决的中继信任决策。

同一个 well-known 地址需要两条独立路径

客户端发现 ohttp 后，会访问与目标同一主机上的 /.well-known/ohttp-gateway。服务器可以用 3xx 把该资源重定向到其他位置。不过，客户端在获取密钥时看到的重定向 URI，绝不能直接交给中继使用。

原因非常具体：网关可以在重定向地址中嵌入只属于这个客户端的值，等中继随后带着该值回来时重新识别它。正确做法是中继自己从 well-known 地址出发，独立跟随重定向；共同适用于所有客户端的结果可以缓存，客户端专属轨迹则不能成为中继路由票据。

因此，审计记录必须保存两条旅程：客户端获取配置时看见了什么，中继投递封装请求时又独立看见了什么。若平台只存一个“最终网关 URL”，就删掉了最能揭示定向重定向的对照证据。

隐私风险发生在受保护请求之前

客户端必须先拿到网关密钥，才能封装请求。RFC 9540 规定客户端向网关发送 GET，并带上 Accept: application/ohttp-keys。如果直接获取，网关会看到客户端 IP 地址。

有些服务只承诺把单次查询与已知订户地址分离，这时暴露“某个地址准备使用 OHTTP”或许可以接受。若承诺包含隐藏位置，或者网关能据此挑选专属配置，则直接获取就与目标冲突。代理可以遮住 IP，却也增加一个新的观察者和日志面。

更深的问题是返回物本身。合法密钥不一定是共同密钥。OHTTP 请求可以通过所用配置被关联；给某人密钥 A、给所有其他人密钥 B，无需破坏密码学就能形成单人群组。RFC 因此建议使用一致性技术，例如通过共享代理确认密钥。发现被定向的配置后，客户端可以停止使用并报告该网关。

运营方必须把“一致”写成可检验定义：比较哪些人群，覆盖多长时间，哪些观测点真正独立，正常轮换如何重叠，差异达到什么阈值时退出。key valid 只回答能否加密；key consistent 才回答自己是否被单独处理。

dohpath 也可能成为身份标签

在 oblivious DoH 场景，解析器还可以通过独有的 dohpath 识别客户端，即使密钥对所有人都相同。RFC 9540 给出两条路：只允许预先知道的单一路径，例如 /dns-query{?dns}；或者用另一来源对任意路径做一致性检查。规范允许根据威胁模型和容量抽样，但抽样只能支撑对样本的判断，不能自动外推到未检查人群。

DDR 与 DNR 也不能混为一谈。DDR 发现的 oblivious DoH 服务仍要执行相应证书验证；DNR 可以通过 DHCP 或路由器通告携带参数，其指定权威另有信任模型。两者都无法凭自身排除独有路径。证书证明谁控制端点身份，不证明该控制者是否向某个客户端发了不同路径。

把“隐私成功”拆成九张凭证

一个可治理的部署至少要分开记录：谁宣告 ohttp；客户端是否理解 mandatory；DDR 或 DNR 指定权威为何被接受；端点身份是否通过；密钥是否可解析；密钥、路径和重定向是否与独立观测一致；中继是否符合政策且可达；交易是否完成；最后，现有证据究竟支持哪一种隐私属性。

这些凭证不能互相补票。请求成功不能追认错误的指定来源，证书有效不能推出密钥相同，密钥相同不能证明中继与网关不存在共同控制。隐私结果是基于多项观察得出的有边界结论，不是协议解析器吐出的布尔值。

RFC 9540 的发现能力因这种克制而更可信。它让客户端找到下一站，也让管理者看到下一站仍然需要什么证据。危险不在于宣告太弱，而在于组织把第一张票据误当成最终裁决。

来源