如今，终端用户承担了过多的在线隐私负担。为了避免第三方跟踪器或定向广告，用户被要求使用 VPN、禁用 Cookie 或安装广告拦截器。与此同时，一些应用开发者最终对用户的了解超出了他们愿意知道的范围：一次典型的客户端-服务器交换会产生一串用户数据痕迹，例如客户端的 IP 地址或 TLS 指纹。这种程度的可见性可能成为一种负担。

这就是 Cloudflare 构建基础设施的原因，帮助开发者将隐私融入他们的应用中。Oblivious HTTP（OHTTP）是一项 IETF 标准，旨在使应用后端能够接收 HTTP 请求而无需看到用户 IP 地址。

今年秋季，我们将推出 Cloudflare OHTTP Gateway。客户将能够以付费附加组件的形式为其 zone 启用我们全新的 OHTTP Gateway，只需点击几下即可开始接收 OHTTP 流量。通过我们的表单注册以加入等待列表。继续阅读以了解更多信息。

扩展我们的 OHTTP 产品套件

在 OHTTP 中，请求经过两个独立运营的跳转节点：中继（relay）和网关（gateway）。OHTTP 中继盲目转发加密请求，以对应用服务器隐藏客户端标识符。OHTTP 网关执行解密加密请求和封装响应的密码学工作，使应用服务器能够像处理普通 HTTP 一样处理 OHTTP 请求。中继和网关之间的信任分离至关重要：它确保没有任何单一实体能同时看到客户端标识符和请求内容。

2022 年，我们推出了 OHTTP 中继产品 Privacy Gateway。Privacy Gateway 使我们的客户能够为其用户提供更加保护隐私的体验。例如，Flo Health 使用 OHTTP 实现其应用的 Anonymous Mode，Apple 的 Private Cloud Compute 使用 OHTTP 将 AI 推理请求与用户身份解关联。但已经在 Cloudflare 后面保护其服务器的客户无法同时使用 Cloudflare 运营的中继——他们需要的是 OHTTP 网关。

在运营 OHTTP 中继的经验中，我们看到了大规模构建和运营一个安全、高性能的 OHTTP 网关有多么困难。今天，我们推出了自助式 Cloudflare OHTTP Gateway 的封闭测试版。我们还将“Privacy Gateway”更名为“Cloudflare OHTTP Relay”，以更好地区分这两个产品。

现在，希望拥有具备必要信任分离的 OHTTP 架构的客户有两种选择：

• 使用 Cloudflare 的 OHTTP Relay（原 Cloudflare Privacy Gateway）并自行运行网关。如果你的应用服务器托管在 Cloudflare 之外，并且你能够运行自己的 OHTTP 网关，这是最佳选择。

• 使用 Cloudflare 全新的 OHTTP Gateway 搭配第三方中继。如果你的应用服务器已经在 Cloudflare 后面（例如在我们的 CDN 或 Workers 上），如果你正在接受来自第三方的 OHTTP 请求（如 Apple 的 LiveCallerID），或者如果你希望使用托管网关来最小化延迟和运维开销，这是最佳选择。

我们正在努力提高整个互联网的隐私标准，我们相信像 OHTTP 这样的协议可以有所帮助——只要我们让它足够容易采用。扩展我们的 OHTTP 产品套件，让我们可信的隐私基础设施惠及更广泛的互联网，这一直是我们的目标。

我们为什么构建 Cloudflare OHTTP Gateway

自从我们推出 OHTTP Relay 产品以来，我们观察到了一些情况。

首先，我们发现开发者对易于访问、可用的隐私基础设施的需求日益增长。注重隐私的应用程序开发者希望默认将网络隐私融入其应用中，但实现这一点仍然比应有的难度更大。

其次，我们了解到构建和运营 OHTTP 网关对客户来说可能很困难。任何代理架构都会引入一定的延迟，因为请求必须在互联网上多经过一两跳。再加上解密请求和加密响应的成本，自建 OHTTP 方案的延迟影响可能非常显著。我们在这方面具有得天独厚的优势：支撑我们为 1.1.1.1 和 iCloud Private Relay 等产品运营快速、可靠隐私基础设施的相同构建模块，使我们成为 OHTTP 网关的理想承载方。得益于 Cloudflare 的任播（anycast）方案，我们的 OHTTP Gateway 将运行在 Cloudflare 全球边缘网络的每台服务器上，从而最大限度地减少中继到网关跳的延迟。如果您使用我们的 CDN，用户请求可以由我们的 Gateway 解密，并在同一 Cloudflare 金属服务器上由您的应用服务器处理，从而节省网关到源的延迟。

最后，请记住 OHTTP 的隐私模型要求中继和应用服务器由独立的、非串通的各方运营。我们希望为客户提供尽可能多的隐私基础设施选项。此前，将应用服务器保护在 Cloudflare 后面的开发者无法使用我们的 OHTTP Relay，因为 Cloudflare 会同时看到客户端元数据和请求的解密内容，从而破坏 OHTTP 的隐私模型。现在，开发者可以选择 Cloudflare OHTTP Relay 或 Gateway 哪个更适合他们的架构。

OHTTP 入门

客户端与应用服务器之间的典型交互会泄露有关客户端的信息。当客户端和应用服务器相互通信时，应用服务器会获知客户端的 IP 地址，因为发送数据的每个数据包都标有源 IP——类似于信封上的“发件人”标签。应用服务器还可以根据支持的 TLS 版本或密码套件等属性对客户端进行“指纹识别”。这些信号使应用服务器能够将多个请求关联回同一用户。

但是，如果我想构建一个真正不太了解用户的应用呢？例如：Flo Health 想要构建一个匿名模式，使用户能够访问个人健康数据，而不会将其与可能的用户标识符关联起来。

OHTTP 引入了一个称为“中继”（relay）的代理，它在客户端和应用服务器之间转发请求和响应，以对应用服务器隐藏客户端的身份。中继可以看到 IP 地址和 TLS 指纹等客户端标识符，但在转发请求之前会将其剥离。这可以防止应用服务器将多个请求关联回同一用户，并意味着请求内容无法与用户的 IP 地址相关联。

例如，常规的客户端-服务器交换可能会泄露以下有关客户端的信息：

- ipAddress: 192.0.2.33 # the client’s IP address
- ASN: 7922
- tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique
- tlsVersion: TLSv1.3
- Country: US
- Region: California # the client's location
- City: Campbell

首先通过 OHTTP 中继发送的请求，只会向接收请求的应用服务器泄露中继的信息：

- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint
- ASN: 18
- tlsCipher: AEAD-AES-128-GCM-SHA256
- tlsVersion: TLSv1.3
- Country: US
- Region: Texas  # the relay's location
- City: Austin

这意味着对于每个请求，应用服务器不会获知最终用户的位置和 TLS 指纹。此外，如果许多不同的用户通过中继发送请求，应用服务器将无法区分哪些请求来自谁，从而限制了其将应用活动追溯到单个最终用户的能力。这创建了一个强大的隐私边界。

然而，OHTTP 与基本转发代理的真正区别在于客户端和应用服务器之间的数据加密。请求和响应使用混合公钥加密（HPKE）进行封装，使得只有客户端和应用服务器可以看到明文，而中继只能看到一堆乱码密文。“网关”（gateway）位于中继和应用服务器之间，处理所有这些加密操作——解封装请求、封装响应——而应用服务器只处理普通 HTTP。

这创建了一个“双盲”隐私模型：中继只能看到客户端标识符；网关和应用服务器只能看到请求内容；没有任何一方能同时看到两者。

我们如何构建 OHTTP 网关

在构建 OHTTP 网关即服务时，我们的目标是将我们安全、高性能的隐私基础设施带给更广泛的互联网。性能和易于接入至关重要。因此，我们将网关构建为一项灵活的服务，部署在我们的全球网络上。只需点击几下，你就可以在你的 zone 上启用网关，并开始向 https://your-zone.com/.well-known/ohttp-gateway 发送 OHTTP。我们会自动扩缩容该服务，因此你无需担心容量问题。

我们还考虑了其他一些用户需求，这些需求来自我们看到的 OHTTP Relay 客户在运营自己的 OHTTP 网关时遇到的痛点。

第一：我们希望为你的应用服务器尽可能多地抽象掉 OHTTP 的复杂性。我们希望开发者能够开始接收 OHTTP，同时如果他们愿意，也可以继续接受常规 HTTP 流量。因此，我们将网关设计为你 zone 的一项功能，客户端向你的 zone 上的 /.well-known/ohttp-gateway 端点发送格式正确的 OHTTP 请求。我们同时支持标准和分块 OHTTP——并且我们推荐使用分块 OHTTP 以获得更好的性能，因为它使我们能够以“块”的形式增量处理请求。

我们的网关服务将拦截每个请求，对其进行解密，向你的应用服务器发起子请求，并向客户端返回加密响应。所有非 OHTTP 请求都将直接到达你的服务器，而不会调用网关。

将你的网关绑定到你的 zone 还使我们能够保护你的网关免遭滥用。向你的 zone `example.com` 发送请求的客户端可以发送到 `foo.example.com` 或 `bar.example.com`，但不能发送到 wikipedia.com。无需你操心，这可以防止未经授权的客户端利用你的 zone 来针对其他域。

第二：无缝密钥管理至关重要。网关需要维护公钥 HPKE 密钥配置，以便客户端加密请求，但安全地管理密钥是一项挑战。因此，我们将网关设计为完全为客户管理所有密钥，并通过对 /.well-known/ohttp-gateway 的 GET 请求将公钥作为响应提供。为了更强的隐私保护，客户端可以通过与其请求网关不同的 IP 下载密钥。

第三：网关需要能够对中继进行身份验证。由于网关（按设计）对发送给定请求的客户端知之甚少，它依赖中继来验证客户端并负责任地转发流量。但是，你如何确保只有受信任的中继才能向你的网关发送流量？

我们将网关设计为在请求被解密之前运行 Cloudflare Access（Cloudflare 的零信任网络访问产品），使你能够使用任何标准 Access 策略来验证传入流量并保护你的网关免遭滥用。选项包括双向 TLS、静态服务凭证和自定义外部逻辑。

最后：错误难免会发生，我们预计客户可能会因在 Cloudflare 上同时运行其 relay 和 gateway 而意外破坏 OHTTP 的隐私模型。因此，为了保持 OHTTP 的信任分离，并确保 Cloudflare 永远不会同时看到客户端身份和解密后的内部请求，我们的网关将拒绝解密来自 Cloudflare Workers 或 Cloudflare 上代理主机的请求。

何时 OHTTP 网关比 OHTTP Relay 更合适？

如果你想使用 Cloudflare 的 OHTTP 产品套件，但又在犹豫为什么应该选择 Cloudflare 的 OHTTP Gateway 而不是 OHTTP Relay，这里有几个考虑因素。

首先，你是否希望将应用服务器部署在 Cloudflare 上——例如，位于我们的 CDN 之后或构建在 Workers 之上？如果是这样，OHTTP Gateway 是更合适的选择，可以确保遵循 OHTTP 的隐私模型。

其次，你的用例是什么？如果你想从第三方客户端接收 OHTTP 请求并进行中继——例如使用 Apple 的 LiveCallerID SDK——那么 OHTTP Gateway 可能是更适合你的解决方案。

开始使用

如果你有功能需求，或者想注册加入我们的等待列表，以便在产品发布时收到通知，请在此处注册。

然后，你需要实现一个 OHTTP 客户端。请参阅 ohttp.info 或我们的示例客户端库，获取一些帮助你入门的示例。在构建客户端时需要注意一点：OHTTP 在网络层面提供隐私保护，不会触及内部请求体。因此，为了保护用户隐私，你需要确保不在请求体中发送可识别身份的信息（例如用户的电子邮件地址或用户名）。

接下来，你需要自备中继。中继可以运行在任何基础设施提供商上，而且它们很简单：这里有一些示例代码。挑战在于——也是你可能需要专门的 OHTTP 中继提供商的原因——你需要能够可验证地向用户承诺，你不会检查带有客户端标识符的日志。否则，你就能够在中继处将客户端与应用服务器上解密后的请求关联起来。

最后，一旦你的 OHTTP 部署上线，请查看我们的 pvcli 客户端，以帮助进行测试和调试。我们很高兴能为各地的开发者带来易于使用的隐私基础设施。如果你想尝试新的 OHTTP Gateway 并提升在线隐私标准，请联系我们。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Cloudflare Blog

原创地址：https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/