Nobody Sees Everything: Inside Cloudflare's OHTTP Gateway

Key takeaways

• Cloudflare renamed its Privacy Gateway to Cloudflare OHTTP Relay and opened a closed beta for Cloudflare OHTTP Gateway, a paid add-on to a customer’s zone. One vendor now sells both halves of the privacy split, separately.
• Oblivious HTTP (RFC 9458, January 2024) divides every request in two. The relay sees who you are (IP address, TLS fingerprint) but never what you asked. The gateway sees what you asked but never who you are. HPKE encryption enforces the split; the independence of the two operators is assumed, not proven.
• The honest limits matter more than the marketing. Identifiers inside the request body still identify you. Gateway logging is a policy choice, not a protocol guarantee. Timing and size analysis can leak around the edges. This is network unlinkability, not anonymity.
• For Canadian privacy teams, OHTTP can shrink the personal information your servers collect, since IP addresses count as personal information here. The due-diligence questions are who operates the relay, what the gateway logs, how keys rotate, and whether the contract actually keeps the two sides from comparing notes.

Your internet provider probably knows more about you than your friends do. Every site you visit, when you visit it, how often you come back, how long you stay. HTTPS hides the contents of the conversation, but the metadata, who talked to whom and when, travels where the network can see it. Correlate that over weeks and you can assemble a startlingly accurate profile of a person without ever reading a single message.

That paragraph is the entire reason Oblivious HTTP exists. And this week, Cloudflare put a product around it.

What Cloudflare actually shipped

Two moves, announced together. First, the rename: Cloudflare’s Privacy Gateway becomes Cloudflare OHTTP Relay. Same job, clearer label. It is the half of the system that sees who you are and never what you asked.

Second, the new thing: Cloudflare OHTTP Gateway, entering closed beta as a paid add-on to a customer’s Cloudflare zone. This is the half that sees what was asked and never who asked it, running across Cloudflare’s global edge network. A customer gets two configurations. Use Cloudflare’s relay and operate your own gateway. Or use Cloudflare’s gateway with a relay run by someone else entirely.

Read that second option slowly, because it is the interesting one. You can now buy the “sees what” half from Cloudflare while the “sees who” half lives with an independent third party. The privacy guarantee of the whole arrangement rests on those two halves never comparing notes. More on that load-bearing assumption later.

Before the mechanics, walk one request through the system. This is the whole protocol in five steps.

The trick, in plain terms

Think of a blind courier service. You write a letter, seal it in an envelope, and hand it to a courier who is contractually forbidden from opening envelopes. The courier knows your address, because you handed them the letter. They deliver the sealed envelope to the recipient. The recipient opens it and reads the letter, but the return address on the envelope says the courier company, not you. Neither party holds both halves of the picture.

OHTTP is that arrangement, enforced with cryptography instead of contracts. Your device fetches the gateway’s public key from a well-known endpoint (/.well-known/ohttp-gateway), then seals the real HTTP request inside using HPKE, Hybrid Public Key Encryption. The relay forwards the sealed package. Only the gateway holds the private key that opens it.

The IETF published this as RFC 9458 in January 2024, authored by Martin Thomson of Mozilla and Christopher Wood of Cloudflare. The RFC is refreshingly honest about what it is: simpler and cheaper than heavier machinery like Tor or Prio, with weaker guarantees to match. It promises unlinkability, not invisibility.

Cloudflare’s gateway speaks two dialects of the protocol, standard and chunked OHTTP, and recommends chunked for incremental processing and better performance. Cloudflare manages the gateway’s HPKE keys for you. And in a genuinely thoughtful touch, Cloudflare Access can authenticate relays before the gateway decrypts anything, so random relays cannot just start feeding your gateway traffic.

Flip the switch below. Same request, two worlds.

What it does not do

Now the part that usually gets buried under the announcement. OHTTP divides trust. It does not remove it.

The non-collusion assumption is the load-bearing wall of the entire design, and it is made of contracts and corporate structure, not mathematics. If the relay operator and the gateway operator are the same company, or two companies that share data freely, the split collapses. One database join reunites “who” with “what.” Nothing in HPKE prevents that. This is exactly why Cloudflare’s gateway refuses requests that arrive from Cloudflare Workers or Cloudflare-proxied hosts: if the relay half sat on Cloudflare infrastructure too, both halves would live under one roof, and the company is enforcing the separation technically rather than asking you to take its word for it. Credit where it is due. That is a real guardrail, and most vendors would have shipped the convenient version.

The second limit is yours to lose. OHTTP hides your network identity from the gateway. It does not hide the request body from the application. If your app puts an email address, a username, or a device ID inside the inner request, the gateway reads it in plaintext. The protocol splits metadata from content; it cannot fix an application that identifies the user by itself. Privacy teams hear this as a familiar lesson wearing new clothes: data minimization still starts with what you collect, not how you transport it.

The remaining limits are quieter. What the gateway logs, and for how long, is a policy decision by whoever operates it. Key distribution matters: your client has to fetch the gateway’s public key from somewhere, and that somewhere becomes infrastructure worth attacking. Timing and request-size analysis can leak information around the edges of any relay design. None of this makes OHTTP useless. It makes it a specific tool with a specific shape, and the shape is “the server stops learning IP addresses,” not “the user becomes anonymous.”

This is already running in the wild

One reason to take the announcement seriously: the pattern is not new. Cloudflare’s post names three deployments already in production. Flo Health uses OHTTP for its Anonymous Mode, the feature that lets users access sensitive health content without the requests being linkable to them. Apple built Private Cloud Compute on OHTTP so that AI requests from iPhones reach Apple’s servers without Apple seeing which device sent what. Apple also uses it for Live Caller ID lookups. These are not lab experiments. They are the reason the IETF bothered to standardize it, and the reason a managed gateway product has customers waiting.

Test your read of the trust model before the last section. Three questions, each answer explains itself.

The Canadian due-diligence read

If you run privacy or vendor risk for a Canadian organization, here is how I would read this announcement operationally.

Start with the minimization angle, because it is real. IP addresses are personal information under Canadian privacy law, and most web servers collect them by default in logs they never look at. An OHTTP gateway in front of your application means your servers stop receiving client IPs at all. That is a smaller data footprint to secure, to retain, and to explain to the OPC. Under Quebec’s Law 25, which already demands minimization and purpose limitation, “we architected it so the data never arrives” is a stronger answer than “we delete it later.” If Bill C-36 becomes law with its own minimization duties, the same answer ports over.

Then ask the questions the marketing will not ask for you. Who operates the relay, and what contractually stops them from sharing data with the gateway operator? What does the gateway log, where do those logs live, and for how long? How do the HPKE keys rotate, and what happens on suspected compromise? Where does decryption physically happen, and does that answer satisfy your data residency requirements? Does the vendor’s own documentation acknowledge the body-identifier trap, or does it let buyers believe transport privacy equals user privacy?

None of this is legal advice. It is procurement hygiene for a technology whose guarantee is exactly as strong as the independence of its two halves.

The open question

Cloudflare has not disclosed pricing, and the gateway is in closed beta, so the honest assessment is that we are looking at a standard with one managed implementation and a rename. The protocol earned its RFC. The ecosystem is the part still being built.

The question I keep coming back to: how many organizations will actually operate their own gateway, and how many will buy Cloudflare’s and then go shopping for a relay operator they trust? The “independent relay” market today is a short list. If it stays short, the non-collusion model rests on very few relationships, and every buyer inherits the same concentration risk they were trying to escape. The cryptography is settled. Whether the market structure around it holds is the part nobody has answered yet.

Primary sources

1. Announcing Cloudflare OHTTP Gateway (Cloudflare)
2. RFC 9458: Oblivious HTTP (IETF)
3. What is Oblivious HTTP? (oblivious.network)