Cloudflare opens OHTTP Gateway closed beta, renames Privacy Gateway

Cloudflare has announced the Cloudflare OHTTP Gateway, a managed gateway for Oblivious HTTP (OHTTP), an IETF standard that lets app backends receive HTTP requests without seeing users' IP addresses. The self-serve product launches as a closed beta, with a waitlist form for interested customers. Cloudflare says the wider launch is planned for this fall, and that customers will be able to switch it on as a paid add-on to their zone with a few clicks. At the same time, it is renaming its 2022 relay product, Privacy Gateway, to Cloudflare OHTTP Relay, to tell the two products apart.

The post explains the model. An OHTTP request passes through two independently-operated hops: a relay and a gateway. The relay blindly forwards encrypted requests and hides client identifiers, such as the IP address and TLS fingerprint, from the app server. The gateway does the cryptographic work: it decapsulates encrypted requests and encapsulates responses, so the app server can treat OHTTP traffic as plain HTTP. Requests are encrypted with Hybrid Public Key Encryption (HPKE), so only the client and the app server see plaintext. The result is what Cloudflare calls a double-blind model: the relay sees only client identifiers, the gateway and app server see only request contents, and no party sees both.

Why a new product? Cloudflare's Privacy Gateway, launched in 2022, was a relay. Customers cited include Flo Health, which uses OHTTP for its app's Anonymous Mode, and Apple's Private Cloud Compute, which uses OHTTP to disassociate AI inference requests from user identities. But customers who already protect their servers behind Cloudflare could not use a Cloudflare-operated relay, because Cloudflare would then see both client metadata and the decrypted contents of requests, which breaks OHTTP's privacy model. They needed a gateway instead. Cloudflare also says its experience running relays showed how hard it is to build and operate a secure, fast gateway at scale, since an extra proxy hop plus the cost of decrypting requests and encrypting responses can add significant latency to a homegrown setup.

Customers now have two options. One is Cloudflare's OHTTP Relay with a gateway they run themselves, best when app servers are hosted off Cloudflare. The other is Cloudflare's new OHTTP Gateway with a third-party relay. Cloudflare recommends that for app servers already behind its CDN or on Workers, for apps accepting OHTTP requests from a third party (it names Apple's LiveCallerID), or for teams that want a managed gateway to cut latency and operational overhead.

On the design, the Gateway is a feature of a customer's zone. Clients send OHTTP requests to a /.well-known/ohttp-gateway endpoint on the zone, for example https://your-zone.com/.well-known/ohttp-gateway, and regular HTTP traffic keeps working; non-OHTTP requests reach the server without invoking the Gateway. Both standard and chunked OHTTP are supported, and Cloudflare recommends chunked OHTTP for better performance because it lets requests be processed incrementally. The service intercepts each request, decrypts it, sends a subrequest to the app server and returns an encrypted response. It scales up and down automatically.

Binding the Gateway to a zone also guards against abuse: a client sending to example.com may reach foo.example.com or bar.example.com but not wikipedia.com, so outsiders cannot use a customer's zone to target other domains. The Gateway fully manages the HPKE keys and serves public keys in response to GET requests to the same endpoint; for stronger privacy, clients can download keys from a different IP than the one they use to send requests. Because the Gateway knows little about the client by design, it trusts the relay to authenticate clients, so Cloudflare Access runs before requests are decrypted. Standard Access policies apply, including mutual TLS, static service credentials and custom external logic. Finally, to keep the separation of trust, the Gateway refuses to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare, which stops customers from accidentally running both relay and gateway on Cloudflare.

Cloudflare says the Gateway will run on every server in its global anycast edge network, minimizing latency in relay-to-gateway hops. If a customer also uses the CDN, requests can be decrypted by the Gateway and resolved by the app servers on the same Cloudflare machines, saving gateway-to-origin latency. It points to the building blocks behind its privacy products such as 1.1.1.1 and iCloud Private Relay as the reason it is well placed to run a gateway.

Key facts

Cloudflare is launching the self-serve OHTTP Gateway as a closed beta with a waitlist; a wider launch is planned for this fall, as a paid add-on to a customer's zone.
Privacy Gateway, Cloudflare's 2022 OHTTP relay product, is renamed Cloudflare OHTTP Relay.
The Gateway targets apps already behind Cloudflare, which could not use a Cloudflare-run relay without breaking OHTTP's privacy model.
Clients send OHTTP to a /.well-known/ohttp-gateway endpoint on the customer's zone; the Gateway manages HPKE keys and supports standard and chunked OHTTP.
Cloudflare Access can authenticate relays before decryption, and the Gateway refuses requests from Cloudflare Workers or proxied Cloudflare hosts.

Why it matters

OHTTP lets an app learn what a request says without learning who sent it, and Cloudflare is now filling the gap on the gateway side. Until now its OHTTP offering was only a relay, which left customers already behind Cloudflare with no way to use it. The post names Apple's Private Cloud Compute, which uses OHTTP to disassociate AI inference requests from user identities, as one example of the protocol in use. Cloudflare argues that a managed gateway removes the latency and operational burden of building one at home.

Who it affects

Developers of privacy-oriented apps whose servers already sit behind Cloudflare's CDN or run on Workers are the main audience. So are teams that accept OHTTP requests from a third party, such as Apple's LiveCallerID, and teams that want a managed gateway instead of running their own. Customers whose servers are hosted off Cloudflare are pointed to the renamed OHTTP Relay plus a gateway of their own.

How to use it

Join the waitlist through Cloudflare's form for the closed beta. Cloudflare says that customers will be able to enable the Gateway as a paid add-on to their zone and start receiving OHTTP traffic with a few clicks. Clients then send OHTTP requests to the /.well-known/ohttp-gateway endpoint on the zone, and fetch public keys with GET requests to the same path. Cloudflare recommends chunked OHTTP for performance. You need a relay run by a separate party, and you can restrict which relays may connect with Cloudflare Access policies such as mutual TLS or static service credentials.

How solid is it

This is Cloudflare's own announcement, so the design claims are its description of the product, not independent testing. The product is in closed beta and general launch is only described as this fall. No latency measurements or benchmarks are given, and no customer is named as already using the new Gateway. The customer examples in the post, Flo Health and Apple's Private Cloud Compute, are tied to OHTTP and the older relay product, not to the Gateway. OHTTP itself is an IETF standard.

Risks and caveats

The privacy guarantee depends on the relay and the gateway being run by separate, non-colluding parties. Cloudflare's Gateway therefore refuses to decrypt requests sent from Cloudflare Workers or proxied hosts on Cloudflare, so a Cloudflare-run relay cannot be paired with it. The Gateway places trust in the relay to authenticate clients and forward traffic responsibly, which is why relay authentication matters. It is a paid add-on and the visible text gives no price. No exact general availability date is given, only this fall.

“the relay sees only client identifiers; the gateway and app server see only request contents; no party sees both.”

— Cloudflare, on OHTTP's double-blind privacy model