Cloudflare’s OHTTP Gateway Refuses to Decrypt Requests That Arrive Through Cloudflare

Cloudflare has opened a closed beta of the Cloudflare OHTTP Gateway, a managed endpoint that decrypts Oblivious HTTP requests on an origin’s behalf. The design decision that drew most of the attention is a refusal rather than a feature: the Gateway will not decrypt requests that reach it from Cloudflare Workers or from hosts proxied through Cloudflare.

Oblivious HTTP, standardized as RFC 9458, splits a request across two parties. The client encrypts the inner HTTP request to the gateway’s public key using HPKE and sends the sealed payload to a relay. The relay sees the client’s IP address but cannot read the request. The gateway decrypts it and forwards plain HTTP to the application, so it sees the contents but only ever sees the relay’s address.

That only works if different operators run the two hops. Putting a Worker in front of the Gateway, or proxying the relay through Cloudflare, would route the client-identifying hop and the decryption hop through the same company, so Cloudflare built a product that declines to run in that configuration. Authors Lara Schull and Akshat Mahajan write that the model "requires that the relay and app server be operated by separate, non-colluding parties."

For a team evaluating this, the practical cost is the relay. Cloudflare does not supply one for the Gateway, and says the component is not the hard part, since relays "can run on any infrastructure provider, and they’re simple." The hard part is being in a position to "verifiably promise to your users that you won’t inspect logs with client identifiers." Cloudflare is also renaming its existing Privacy Gateway to Cloudflare OHTTP Relay to separate the two sides.

The Gateway itself binds to a zone and listens at a fixed path, https://your-zone.com/.well-known/ohttp-gateway, which stops a customer from pointing their gateway at another domain. Cloudflare manages the HPKE keys and serves the public keys from that same path in response to a GET, and clients can fetch keys over a different IP address than the one they use for requests. Standard and chunked OHTTP both work, with chunked recommended for performance. Cloudflare Access runs before decryption, so the relay itself can be authenticated with mutual TLS, static service credentials, or custom external logic.

Protection stops at the network layer, and Cloudflare says so. OHTTP "provides privacy at the network level, and doesn’t touch the inner request body," the post notes, adding that "it’s up to you not to send identifying information (e.g. a user’s email address or username) in the request body." Put a session token or an email address inside the sealed request and the gateway operator has the identity the protocol was meant to withhold.

Discussion on Hacker News divided between readers working out where the protocol fits and readers naming what it costs. Commenter johnhess set out the fit:

This separates who sees what. Cloudflare (or any OHTTP gateway) sees who talks to who, but can’t see the content. The service sees the content but not who you are/your IP. You can imagine a lot of threat models where who you talk to isn’t sensitive, nor is "someone talked to them about X" but knowing both facts is a risk.

Commenter gsnedders gave the most detailed comparison, measuring OHTTP against the obvious do-it-yourself alternative of a SOCKS5 proxy:

OHTTP is designed for a relatively narrow use case: stateless requests where you don’t want the gateway to be able to correlate multiple requests from the same client (i.e., it’s not just about hiding the IP address).

Matching that with SOCKS5, he wrote, means a new TCP connection for every request, no TLS session resumption or 0-RTT, and a deliberately conservative ClientHello, because SOCKS5 is unencrypted and carries the destination in the clear. OHTTP keeps the TLS fingerprinting surface away from the gateway and allows long-lived connections from client to relay and relay to gateway, which he called a significant latency win for workloads like DNS over HTTPS. He also named what the design gives up:

With OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less.

The pointed questions were operational. Commenter arshxyz asked about a product interaction the announcement does not address:

Does Cloudflare’s WAF (which relies on TLS Fingerprinting) stop working if OHTTP is enabled? If not, does this imply the client metadata is read and processed by Cloudflare but not passed on to the application server?

Commenter Joker_vD asked how IP-based banning survives, and commenter blantonl described the position an operator ends up in: "I respect customer privacy. But I also need to know who is abusing my platforms as well." Commenter thayne raised the aggregation point, noting that when one entity serves a large share of the internet it ends up holding a record of which sites a given IP visited and which IPs visited a given customer, while conceding "that is still better than them having the source ip and the content."

If these reactions are representative, the cryptography is not what teams will argue about. Nobody in the thread disputed that the split works as described. The questions were whether a client exists that speaks the protocol, what a self-hosted relay is worth, and what breaks on the Cloudflare side once the client metadata is gone. Commenter ranger_danger asked whether any current proxy, tunnel, or VPN software supports OHTTP as a transport, which is the adoption question for anyone not shipping their own app. On self-hosting, commenter palata pointed out that a relay run for a handful of people defeats its own purpose, because the service then knows any request through it came from that small group. Commenter scosman described the demand side from experience, saying he had wanted this for update checks in otherwise offline transcription software and ended up calling GitHub releases directly. Commenter freedomben questioned charging for it at all, calling a paid privacy add-on "a poor incentive if the goal is to improve privacy generally."

The closest comparison in the thread was Tor, which commenter maayank reduced to "OHTTP is like a two-hop Tor circuit with a predetermined gateway." The difference is scope. OHTTP needs a client that deliberately speaks the protocol to a known gateway, so it is not general browsing privacy. It fits an app vendor that wants telemetry, inference, or a lookup feature without being able to tie each request to a user. Cloudflare cites Flo Health’s Anonymous Mode and Apple’s Private Cloud Compute as production deployments, with Apple’s LiveCallerID as the case where a service accepts OHTTP from a third party. Cloudflare’s Reference Image work with Apple, which InfoQ covered earlier this year, uses the same transport to request timestamps without revealing who asked.

Cloudflare says the Gateway launches this fall, with a closed beta of the self-serve version starting now. It will be sold as a paid add-on to a customer’s zone, and the announcement does not publish a price. Interested teams can register through a waitlist form.