Cloudflare近期启动OHTTP网关封闭测试，核心设定为托管端点，可在不解密状态下处理Oblivious HTTP请求。该方案采用加密拆分传输、中继仅可获取客户端IP而不可读取内容的方式，实现请求隐私保护。但存在明确限制：当请求来自Cloudflare Workers或代理主机时，网关拒绝解密，需通过部署独立Worker或通过Cloudflare代理中继流量来规避限制。该设计明确要求中继服务器与应用服务器由独立运营方支撑，以保障隐私。技术层面，OHTTP将TLS指纹攻击面与网关隔离，支持长连接以优化DNS over HTTPS等场景性能，但也存在密钥泄露影响面、未覆盖的适用场景等落地问题。讨论中呈现两极分化观点，既有受众关注其隐私保护价值，也有用户指出其适用场景狭窄、自托管中继价值有限、付费机制可能偏离隐私改善等争议，反映出该方案在隐私保护与实际应用场景上的平衡挑战。

--91likeyou---

对于评估该方案的团队而言，实际成本在于中继服务器。Cloudflare 并未为网关提供中继服务器，并且说该组件并非难点，因为中继服务器“可以在任何基础设施提供商那里运行，而且实现简单”。真正的难点在于能否“向用户做出可验证的承诺，即不会检查包含客户端标识符的日志”。Cloudflare 还将现有的 Privacy Gateway 更名为 Cloudflare OHTTP Relay，以区分这两种方案。

网关本身绑定了到一个区域，并监听一个固定的路径： 管理 HPKE 密钥，并在响应 GET 请求时通过该路径提供公钥，客户端可以通过与请求 IP 地址不同的 IP 获取密钥。标准 OHTTP 和分块 OHTTP 都可以使用，出于性能考虑，建议使用分块 OHTTP。Cloudflare Access 在解密之前运行，因此，中继服务器本身可以通过双向 TLS、静态服务凭据或自定义外部逻辑进行身份验证。

保护仅限于网络层，Cloudflare 也是这么说的。该博文指出，OHTTP “在网络层提供隐私保护，而且不会触及请求内部的正文内容”，并补充道：“是否在请求正文中发送可识别身份的信息（例如用户的电子邮件地址或用户名），取决于你自己。”如果在密封的请求中放入会话令牌或电子邮件地址，那么网关运营商便会获取该协议本应隐藏的身份信息。

Hacker News 上的讨论呈现了两极分化：一部分读者在探讨该协议的适用场景，另一部分读者则在指出其代价。评论者 johnhess 阐述了其适用场景：

这可以区分谁能看到什么内容。Cloudflare 或任何 OHTTP 网关都能看到谁与谁通信，但无法看到内容本身。该服务能看到内容，却无法识别你的身份或 IP 地址。你可以设想出许多威胁模型：你与谁通信并不敏感，“某人曾与他们讨论过 X ”这一事实也不敏感，但同时知晓这两点则会构成风险。

评论者 gsnedders 给出了最详细的对比分析，将 OHTTP 与显而易见的自建替代方案——SOCKS5 代理——进行了对比：

OHTTP 的设计使用场景相对狭窄：无状态请求。在这种情况下，你不希望网关能够将同一客户端发出的多个请求关联起来（也就是说，这不仅仅是为了隐藏 IP 地址）。

他写道，如果与 SOCKS5 结合使用，则意味着每个请求都需要建立新的 TCP 连接，不能进行 TLS 会话恢复或 0-RTT，而且 ClientHello 要设置得相当保守——因为 SOCKS5 未加密，是以明文形式传输目标地址。OHTTP 将 TLS 指纹识别攻击面与网关隔离，并允许在客户端与中继以及中继与网关之间建立长连接。他说，这对 DNS over HTTPS 等工作负载而言是一项显著的延迟优化。他还指出了该设计所做出的妥协：

在 OHTTP 中，网关密钥的泄露本质上意味着中继服务器可以解密使用了该密钥的已记录流量（因为不存在前向保密），而客户端 中继服务器以及中继服务器 网关之间的密钥泄露影响则要小得多。

这些有针对性的问题都聚焦在实际的落地运营层面。评论者 arshxyz 询问了公告中未提及的一个产品交互问题：

如果启用了 OHTTP，Cloudflare 的 WAF（该功能依赖于 TLS 指纹识别）是否会停止工作？如果不会，这是否意味着客户端元数据会被 Cloudflare 读取和处理，但不会传递给应用服务器？

评论者 Joker_vD 询问基于 IP 地址的封禁机制如何得以维持，而评论者 blantonl 则描述了运营商最终将面临的处境：“我尊重客户的隐私。但我同时也需要知道是谁在滥用我的平台。”评论者 thayne 则提出了数据聚合的问题。他指出，当某个实体占据互联网的大部分份额时，它最终会掌握特定 IP 访问过哪些网站以及哪些 IP 访问过特定用户的记录。但他同时也承认：“这总比他们掌握源 IP 和内容要好。”

如果这些反应具有代表性，那么就可以说明，加密机制本身没有成为各团队争论的焦点。在这个讨论贴中，没有人质疑这种拆分机制是否会如描述的那样运作。大家关注的问题在于：是否存在支持该协议的客户端、自托管中继服务器的价值何在，以及一旦客户端元数据消失，Cloudflare 方面会出现哪些问题。评论者 ranger_danger 问道，是否有现有的代理、隧道或 VPN 软件支持 OHTTP 传输协议，对于未发布自有应用的开发者而言，这是影响他们采用的关键问题。关于自托管，评论者 palata 指出，仅为少数人运行的中继服务器会背离其设计初衷，因为服务方将知晓所有经由该中继服务器的请求均来自这个小群体。评论者 scosman 结合自身经验描述了需求端的情况。他表示，自己曾经希望在原本离线的转录软件中使用该功能进行更新检查，结果是他最终只能直接调用 GitHub 发布接口。评论者 freedomben 则对该服务是否应该收费表达了质疑。他指出，如果目标是普遍性地改善隐私，那么付费隐私插件“将是一种糟糕的激励机制”。

在这个讨论贴中，有一个与之最接近的类比是 Tor。评论者 maayank 将其概括为：“OHTTP 就像一个带有预设网关的两跳 Tor 电路。”两者的区别在于适用范围。OHTTP 需要客户端有意识地通过该协议与已知网关进行通信，因此它并非通用的浏览隐私解决方案。它适合希望获取遥测数据、进行推断或提供查询功能，但又无法将每次请求与特定用户关联的应用供应商。Cloudflare 援引了将 Flo Health “匿名模式”和苹果“私有云计算”作为生产环境部署的案例，把苹果的 LiveCallerID 作为服务接受第三方 OHTTP 请求。Cloudflare 与苹果合作的“参考镜像”（Reference Image）项目—— 今年早些时候曾经报道过——也使用了相同的传输协议来请求时间戳，同时不透露请求者的身份。

Cloudflare 表示，该网关将于今年秋季正式推出，目前其自助服务版本已经开启封闭测试。该服务将作为客户区域的付费增值组件进行销售，但公告中未公布具体价格。感兴趣的团队可以通过候补表单进行注册。

：

🔥 热词：#cloudflare 到 aws alb 的请求头 · #cloudflare禁止访问的解决方法 · #cloudflare是最强的网络安全公司吗 · #cloudflare哪些443端口开放的 · #cloudflare支持的端口 · #cloudflare在互联网中的位置 · #cloudflare实现内网穿透 · #cloudflare拦截国外访问