Cloudflare OHTTP Gateway

Today, end users carry too much of the burden of online privacy. To avoid third-party trackers or targeted ads, users are instructed to use a VPN, disable cookies, or install adblockers. Meanwhile, some app developers end up knowing more about their users than they’d care to: a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.

如今，终端用户在网络隐私方面承担了过多的负担。为了避开第三方追踪器或定向广告，用户被告知要使用 VPN、禁用 Cookie 或安装广告拦截器。与此同时，一些应用开发者最终获取的用户信息比他们预想的还要多：典型的客户端-服务器交互会留下用户数据轨迹，例如客户端的 IP 地址或 TLS 指纹。这种程度的可见性可能成为一种负担。

That’s why Cloudflare builds infrastructure that helps developers bake privacy into their apps. Oblivious HTTP (OHTTP) is an IETF standard designed to enable app backends to receive HTTP requests without seeing user IP addresses. This fall, we’re launching the Cloudflare OHTTP Gateway. Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks. Register through our form to join our waitlist. Read on to learn more.

正因如此，Cloudflare 致力于构建基础设施，帮助开发者将隐私保护融入其应用程序中。Oblivious HTTP (OHTTP) 是一项 IETF 标准，旨在使应用后端能够在不查看用户 IP 地址的情况下接收 HTTP 请求。今年秋季，我们将推出 Cloudflare OHTTP Gateway。客户可以将我们新的 OHTTP Gateway 作为其区域的付费附加组件启用，只需点击几下即可开始接收 OHTTP 流量。请通过我们的表格注册以加入候补名单。继续阅读以了解更多信息。

Expanding our OHTTP product suite

扩展我们的 OHTTP 产品套件

With OHTTP, requests travel through two independently-operated hops: a relay and a gateway. An OHTTP relay blindly forwards encrypted requests in order to hide client identifiers from app servers. An OHTTP gateway performs the cryptographic work of decapsulating encrypted requests and encapsulating responses such that app servers can handle OHTTP requests as if they were plain HTTP. The separation of trust between relay and gateway is critical: it ensures that no single party sees both client identifiers and request contents.

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

In 2022, we launched an OHTTP relay product, Privacy Gateway. Privacy Gateway enables our customers to offer more privacy-preserving experiences to their users. For example, Flo Health uses OHTTP for their app’s Anonymous Mode, and Apple’s Private Cloud Compute uses OHTTP to disassociate AI inference requests from user identities. But customers who are already protecting their servers behind Cloudflare can’t also use a Cloudflare-operated relay — they need an OHTTP gateway instead.

2022 年，我们推出了 OHTTP 中继产品 Privacy Gateway。Privacy Gateway 使我们的客户能够为用户提供更具隐私保护的体验。例如，Flo Health 在其应用的“匿名模式”中使用 OHTTP，而 Apple 的 Private Cloud Compute 则使用 OHTTP 将 AI 推理请求与用户身份解耦。但是，那些已经通过 Cloudflare 保护其服务器的客户无法同时使用 Cloudflare 运营的中继——他们需要的是 OHTTP 网关。

With the existing Cloudflare OHTTP Relay, customers must bring their own Gateway to preserve a separation of trust. In our experience running OHTTP relays, we’ve seen how difficult it can be to build and operate a secure, performant OHTTP gateway at scale. Today, we’re launching the closed beta for our self-serve Cloudflare OHTTP Gateway. We’re also renaming our “Privacy Gateway” to “Cloudflare OHTTP Relay” to better distinguish the two products.

在使用现有的 Cloudflare OHTTP Relay 时，客户必须自带网关以保持信任分离。根据我们运营 OHTTP 中继的经验，我们深知大规模构建和运营一个安全、高性能的 OHTTP 网关有多么困难。今天，我们正式推出自助式 Cloudflare OHTTP Gateway 的封闭测试版。我们还将“Privacy Gateway”更名为“Cloudflare OHTTP Relay”，以便更好地进行产品区分。

Now, customers who want an OHTTP architecture with the necessary separation of trust have two options:

1. Use Cloudflare’s OHTTP Relay (formerly Cloudflare Privacy Gateway) and run your gateway yourself. This is best if your application servers are hosted off Cloudflare, and you’re able to run your own OHTTP gateway.
2. Use Cloudflare’s new OHTTP Gateway with a third-party relay. This is best if your app servers are already behind Cloudflare (on our CDN or Workers, for example), if you’re accepting OHTTP requests from a third party (like Apple’s LiveCallerID), or if you want a managed gateway to minimize latency and operational overhead.

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

1. 使用 Cloudflare 的 OHTTP Relay（原 Cloudflare Privacy Gateway）并自行运行网关。 如果您的应用服务器托管在 Cloudflare 之外，并且您有能力运行自己的 OHTTP 网关，这是最佳选择。
2. 使用 Cloudflare 新的 OHTTP Gateway 并搭配第三方中继。 如果您的应用服务器已经在 Cloudflare 保护之下（例如在我们的 CDN 或 Workers 上）、如果您正在接收来自第三方（如 Apple 的 LiveCallerID）的 OHTTP 请求，或者如果您希望通过托管网关来最小化延迟和运营开销，这是最佳选择。

We’re working to raise the bar for privacy across the Internet, and we believe that protocols like OHTTP can help — if we make them easy enough to adopt. It’s always been our goal to expand our OHTTP product suite and make our trusted privacy infrastructure accessible to a broader swath of the Internet.

我们致力于提高整个互联网的隐私标准，并相信像 OHTTP 这样的协议能够提供帮助——前提是我们能让它们足够易于采用。我们的目标始终是扩展 OHTTP 产品套件，并让更广泛的互联网用户能够使用我们值得信赖的隐私基础设施。

Why we built the Cloudflare OHTTP Gateway

我们为何构建 Cloudflare OHTTP Gateway

Since we launched our OHTTP Relay product, we’ve observed a few things. First, we’ve seen that there’s a growing appetite among developers for accessible, usable privacy infrastructure. Developers of privacy-oriented apps want to bake network privacy into their applications by default, but doing so remains harder than it should be. Second, we’ve learned that building and operating an OHTTP gateway can be tough for customers. Any proxying architecture introduces some latency because requests must travel an extra hop or two around the Internet. Combine that with the cost to decrypt requests and encrypt responses, and the latency hit of a homegrown OHTTP setup can be significant.

自我们推出 OHTTP Relay 产品以来，我们观察到了一些情况。首先，我们发现开发者对易于获取和使用的隐私基础设施的需求日益增长。注重隐私的应用开发者希望默认将网络隐私融入其应用程序中，但实现这一目标仍然比预想的要困难。其次，我们了解到，对于客户而言，构建和运营 OHTTP 网关可能非常棘手。任何代理架构都会引入一定的延迟，因为请求必须在互联网上多经过一两个节点。再加上解密请求和加密响应的成本，自建 OHTTP 设置所带来的延迟影响可能是巨大的。

We’re well-positioned to solve this problem: the same building blocks that enable us to operate fast, reliable privacy infrastructure for products like 1.1.1.1 and iCloud Private Relay make us a good home for an OHTTP gateway. Because of Cloudflare’s anycast approach, our OHTTP Gateway will run on every server on Cloudflare’s global edge network, minimizing latency in relay-to-gateway hops. If you use our CDN, user requests can be decrypted by our Gateway and resolved by your app servers on the same Cloudflare metals, saving gateway-to-origin latency.

我们完全有能力解决这个问题：使我们能够为 1.1.1.1 和 iCloud Private Relay 等产品运营快速、可靠的隐私基础设施的底层技术，同样使我们成为 OHTTP 网关的理想平台。得益于 Cloudflare 的任播（Anycast）架构，我们的 OHTTP Gateway 将运行在 Cloudflare 全球边缘网络的每一台服务器上，从而最大限度地减少中继到网关之间的延迟。如果您使用我们的 CDN，用户请求可以由我们的网关解密，并由您的应用服务器在同一台 Cloudflare 物理机上进行解析，从而节省网关到源站的延迟。

Finally, recall that OHTTP’s privacy model requires that the relay and app server be operated by separate, non-colluding parties. We want to provide our customers with the best possible range of options for their privacy infrastructure. Before, developers who protected their app servers behind Cloudflare weren’t able to use our OHTTP Relay, because Cloudflare would see both client metadata and the decrypted contents of requests, breaking OHTTP’s privacy model. Now, developers can choose whether a Cloudflare OHTTP Relay or Gateway is a better fit for their architecture.

最后，请记住，OHTTP 的隐私模型要求中继和应用服务器由互不勾结的独立方运营。我们希望为客户提供尽可能丰富的隐私基础设施选择。此前，将应用服务器置于 Cloudflare 保护之下的开发者无法使用我们的 OHTTP Relay，因为 Cloudflare 会同时看到客户端元数据和解密后的请求内容，从而破坏了 OHTTP 的隐私模型。现在，开发者可以根据其架构需求，选择 Cloudflare OHTTP Relay 或 Gateway。

A primer on OHTTP

OHTTP 入门

A typical interaction between a client and application server reveals information about the client. When a client and app server talk to one another, the app server learns the client’s IP address because each packet in which data is sent is labeled with a source IP — similar to the “from” label on an envelope. App servers can also “fingerprint” a client based on attributes like supported TLS versions or cipher suites. These signals make it possible for app servers to link multiple requests back to the same user.

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

But what if I wanted to build an app that really doesn’t know much about my users? For example: Flo Health wanted to build an Anonymous Mode to enable users to access personal health data without it being linkable to possible user identities.

但如果我想构建一个真正不了解用户信息的应用程序该怎么办？例如：Flo Health 希望构建一种“匿名模式”，使用户能够访问个人健康数据，而这些数据不会与潜在的用户身份关联。