Cloudflare OHTTP gateway
Cloudflare is launching a closed beta for its new OHTTP Gateway, allowing applications hosted on its infrastructure to receive Oblivious HTTP traffic securely.
summary is enough Useful announcement for architects evaluating OHTTP, though the post reads largely like a standard product launch.
summary
Cloudflare is introducing a managed OHTTP Gateway to complement its existing OHTTP Relay, enabling apps hosted on its CDN or Workers to receive encrypted requests without seeing client IP addresses. The protocol uses a double-blind trust model where a third-party relay sees the client metadata and Cloudflare's gateway sees the content, but neither sees both. To maintain compliance with the OHTTP standard, Cloudflare restricts customers from running both the relay and gateway on its network. The service is currently available via a waitlist as a paid add-on.
key points
- OHTTP uses a split-trust architecture where a relay handles client metadata and a gateway handles request content, preventing any single entity from seeing both.
- Cloudflare's new OHTTP Gateway is intended for origins hosted on Cloudflare, requiring users to pair it with a separate, third-party relay.
- The service manages public HPKE key configurations automatically and integrates with Cloudflare Access for relay authentication.
who should read it
Backend architects and security engineers interested in implementing network-level user privacy.
discussion skeptical
consensus
Commenters are skeptical about Cloudflare centralizing more internet infrastructure under the banner of privacy, arguing that routing traffic through them just shifts tracking to another massive entity.
pushback
Some defenders emphasize that the cryptographic separation mathematically prevents Cloudflare from correlating user IPs with request payloads, separating metadata from content.
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.
It succinctly clarifies the exact threat model and separation of responsibilities that confused several participants in the thread.
Generated by an LLM from the article and thread. Check the sources before relying on it.