Cloudflare's OHTTP Gateway Beta Gives Apps a New Choice

Cloudflare announced a closed beta for its OHTTP Gateway on October 2, offering developers whose applications already sit behind Cloudflare a new way to handle privacy-preserving requests. A developer can use Cloudflare to run the gateway while a separate organization runs the relay. Cloudflare also renamed its existing Privacy Gateway product Cloudflare OHTTP Relay. Those are two different jobs, and the privacy design depends on keeping them apart.

For a developer using Cloudflare’s CDN or Workers, the new gateway option changes who can operate the component that decrypts an incoming request. It does not eliminate the need to find a relay or change what information the application puts in that request. If you are evaluating the beta, start with the organizational chart, not the product names: who handles the client connection, and who can read the message?

What the Gateway Changes

Oblivious HTTP, or OHTTP, sends an encrypted HTTP request from a client through a relay to a gateway. The gateway decrypts the message so the application can handle it, then prepares an encrypted response to travel back through the relay. Under RFC 9458’s protocol design, the relay sees the client connection but cannot read the plaintext HTTP message. The gateway can read the message but does not see the client’s IP address through that connection.

Think of the relay as knowing who arrived with a sealed envelope and the gateway as opening it after the sender’s return address has been left behind. The envelope may still contain a name. OHTTP separates information about the network connection from the contents of the request; an account identifier in the request can still identify the person to the application.

The new product gives Cloudflare customers a different way to assign those jobs. Cloudflare says that if it ran the relay while also handling decrypted traffic for an app behind its network, it would see both client metadata and request contents. In its proposed gateway arrangement, a third party operates the relay and Cloudflare operates the gateway. That preserves the intended split if the operators remain separate and do not collude. The RFC describes what OHTTP is designed to protect; it does not establish how any particular beta deployment performs.

There is a practical appeal to paying a provider to run the gateway. Cloudflare says operating one involves decrypting requests, encrypting responses and managing the latency introduced by an extra hop. It plans to offer the gateway as a paid add-on to a customer’s zone and describes the current offering as a closed beta with a waitlist. Those details put a limit on the announcement: customers cannot assume every request to an app behind Cloudflare has started using OHTTP, and developers still need a willing relay and clients configured to use it.

Why the Older Product Could Not Fill This Role

Cloudflare dates its Privacy Gateway relay product to 2022. A Cloudflare technical post from October that year described it as a managed OHTTP relay, while the company’s current announcement supplies the retrospective account of its launch. RFC 9458 followed in January 2024 as an IETF Standards Track document. The product that Cloudflare has renamed OHTTP Relay remains the relay option; the beta adds a gateway option alongside it.

The earlier arrangement suited a developer who could operate a gateway separately and use Cloudflare for the relay. It was an awkward fit for an app already behind Cloudflare: by Cloudflare’s account of its architecture, using its relay as well would put client metadata and decrypted traffic within one operator’s reach. The developer needed to place the relay elsewhere and arrange for a gateway. With the beta, Cloudflare offers to take on that gateway work while the relay stays with a third party.

That could remove one piece of infrastructure from the developer’s operating list. It adds a procurement and trust decision the developer cannot outsource to the gateway: who runs the relay, and is that operator separate from whoever handles the decrypted request? A useful deployment diagram should mark the client, relay, gateway and application with their operators’ names. If one organization ends up on both sides of the intended boundary, paying for two components has not bought the intended separation.

The request format deserves the same scrutiny. RFC 9458 gives DNS queries and telemetry submissions as examples of messages for which separating sender from content may be useful. It also cautions that cookies, authentication and other state carried between requests can let an application link them despite the network-level separation. An app that sends a signed-in account identifier to the gateway cannot rely on a hidden IP address to keep that account unknown to the recipient. Developers need to decide which requests benefit from OHTTP and which identifying fields those requests require.

Why the Tor Comparison Has Limits

Cloudflare’s 2022 technical explanation calls OHTTP an application-layer proxy: it forwards HTTP messages rather than proxying a network connection. The application must participate in sending its messages through the relay and gateway. A user browsing an unrelated website does not gain this protection merely because that site uses Cloudflare.

Tor also routes through intermediaries, but its documented path has a different shape. The Tor Project’s circuit example runs from a user through a guard relay, a middle relay and an exit relay to a destination. The destination sees the exit relay’s IP address instead of the user’s. OHTTP handles designated HTTP messages for a participating application. Counting the intermediaries would obscure what each architecture routes and where the destination sits. This comparison does not rank their privacy or performance for a given use.

For an app user, the useful question is narrower than whether an app advertises OHTTP: which of its requests take that route? For its developer, the test is more exacting. Identify the relay operator, identify who decrypts the message, and inspect what the message says about its sender. Cloudflare’s beta offers someone to run the gateway. The app still determines what goes into the envelope.