Cloudflare OHTTP Gateway: Privacy Depends on Who Runs Each Hop
A server normally learns two things when a client calls it: where the connection came from and what the request says. The source IP address and TLS connection offer network clues; the URL, headers, and body carry the application data. Sometimes a service needs the latter to do its job but has no reason to receive the former. An anonymous health feature, a safety lookup, or a private AI request is easier to trust when the server cannot join a person’s network identity to the action they took.
Cloudflare’s newly announced OHTTP Gateway makes one half of an Oblivious HTTP deployment available as a managed service. It is entering a closed beta as a paid add-on for Cloudflare zones. This matters because Cloudflare already offered the other half, an OHTTP relay, under the former name Privacy Gateway. The two services solve different problems, and the privacy promise depends on choosing only one of them for a given request path.
What Oblivious HTTP separates
RFC 9458 defines a client, relay, gateway, and target service. The client obtains the gateway’s public key configuration, packages an HTTP request in binary form, and encrypts it. It sends that sealed message to the relay. The relay sees the client’s connection and forwards the encrypted message to the gateway. The gateway opens it and sends a normal request to the target application. The response takes the reverse route, encrypted again before it crosses the relay.
The relay can see who connected, but cannot read the inner request. The gateway and application can read what was requested, but see the relay’s connection rather than the client’s. The relay and gateway must be run by parties that do not collude. This is the point of the architecture, not merely a performance or deployment preference.
This is stronger than sending ordinary HTTP through a single proxy. A conventional proxy could see both the connecting client and the request contents. OHTTP uses Hybrid Public Key Encryption so the relay cannot open the inner message. The gateway holds the private key and decapsulates the request; the client and gateway establish the cryptographic context needed to protect the reply. The target application still receives an ordinary HTTP request and does not need to implement the wire protocol itself.
The design has a precise scope. It hides the client’s network identity from the gateway and target, and it hides the inner HTTP message from the relay. It does not erase identifiers the application deliberately puts inside that message. A username, account token, email address, or uniquely identifying query can still tell the target who the user is. Browser cookies and other application-level state also need a deliberate policy. OHTTP is a network privacy building block, not an automatic anonymous mode for every API.
Why Cloudflare added the gateway
Cloudflare launched a managed OHTTP relay in 2022. A customer using that relay had to operate its own gateway. That arrangement works when the application is hosted elsewhere: Cloudflare can know the client’s network details at the relay while the customer’s gateway sees the decrypted request. Cloudflare says this model supports privacy features such as Flo Health’s Anonymous Mode and Apple’s Private Cloud Compute request separation.
It becomes unsuitable when the same customer also puts its gateway or application behind Cloudflare. In that topology, Cloudflare could operate the relay that sees the client IP and the service that decrypts the request. The protocol’s separation of duties would collapse even if the messages were encrypted correctly on the wire. The new managed gateway fills the other side of the choice: use Cloudflare for decryption and application delivery, then bring an independently operated relay.
That is why the product naming changed. Privacy Gateway is now Cloudflare OHTTP Relay, while the new product is Cloudflare OHTTP Gateway. The name identifies which trust boundary Cloudflare occupies. If a service already runs on Cloudflare CDN or Workers, the gateway is the natural fit. It is also useful when an external system sends OHTTP traffic through its own relay, such as Apple’s Live Caller ID integration. If the application and gateway are outside Cloudflare, its relay may be the better fit.
What the managed gateway actually does
The gateway is configured on a Cloudflare zone. Clients send OHTTP traffic to https://your-zone.com/.well-known/ohttp-gateway. Cloudflare intercepts the OHTTP request, decrypts it, issues a subrequest to the application, encrypts the response, and returns it along the relay path. Ordinary requests to the zone continue to the server without invoking the gateway. That lets a service accept both conventional and oblivious traffic while it migrates a particular feature.
Cloudflare says the service runs across its anycast edge and scales with traffic. Locating decryption close to an application already on Cloudflare can reduce the extra network distance between gateway and origin. There is still an additional relay hop and cryptographic work, so this is an architectural latency improvement rather than a promise of zero overhead. The service supports standard OHTTP and chunked OHTTP; Cloudflare recommends the chunked form because it can process a stream incrementally instead of waiting for the whole message.
The gateway also manages its HPKE keys. A GET request to the well-known endpoint supplies the public key configuration the client needs before it can encrypt a request. Cloudflare suggests fetching keys over a different IP path from the one used for requests when a deployment wants stronger unlinkability. Key distribution, rotation, and client configuration matter in practice: a client that encrypts to the wrong key or trusts an unverified configuration cannot complete the intended private exchange.
The gateway is scoped to the customer’s zone, so it cannot become an open proxy for arbitrary destinations. A request can address the permitted hosts within that zone; it cannot use the gateway as a tunnel to an unrelated domain. Cloudflare also places Cloudflare Access before decryption, allowing operators to authenticate relays with policies such as mutual TLS or service credentials. That protects the gateway from unauthorized traffic without asking it to identify the end user whose request it is designed not to know.
Cloudflare has built an additional guardrail into the product: its gateway refuses to decrypt OHTTP requests arriving from Cloudflare Workers or proxied Cloudflare hosts. This blocks an easy accidental deployment of Cloudflare on both sides of the privacy boundary. It does not replace the broader responsibility to choose an independent relay operator and inspect the whole logging and request path.
A deployment checklist grounded in the privacy model
First, decide which party sees the client connection. For the new Cloudflare gateway, that must be a third-party relay. A relay is mechanically simple—it forwards encrypted messages—but its operational promises matter. If the application operator can inspect relay logs containing client IPs and compare them with decrypted application requests, the separation is only cosmetic. Independent ownership, limited logging, and a clear threat model are as important as the protocol implementation.
Second, build or adopt an OHTTP client. It must fetch and validate the gateway’s public key configuration, encode and encrypt the inner request, send it through the selected relay, and decrypt the reply. The OHTTP specification is the protocol reference; Cloudflare also points developers to sample client and relay implementations. Its open-source pvcli can exercise an end-to-end flow and show which hop failed when a request is rejected.
Third, audit the inner request. If the desired feature should be anonymous, do not include an account ID, bearer token, email, or a stable client-generated identifier just because the network route is private. Decide whether responses should be cacheable, whether retries can be correlated, and what each operator logs. Application authentication and abuse protection may still be necessary, but they must be designed without silently reconstructing the identity link OHTTP was meant to remove.
Finally, measure the whole path. Relay location, gateway placement, key fetches, request size, and chunking all affect latency. Access policies and origin routing can introduce failures that look like cryptographic problems. Test both the OHTTP endpoint and ordinary requests, then verify that the target sees the gateway’s connection rather than the end user’s IP. The closed beta and waitlist mean teams should treat the managed gateway as an upcoming integration to evaluate, not a generally available switch that every account can turn on today.
The real boundary
Cloudflare’s announcement is useful because it turns a hard-to-run protocol component into a zone feature. The deeper lesson is about custody of information. OHTTP works when one independent party handles the address label and another handles the sealed contents. A managed gateway reduces deployment and key-management work, but the privacy guarantee still comes from keeping those roles apart—and from avoiding identifying data inside the request itself.