Cloudflare's OHTTP Gateway Blocks Internal Requests for Privacy

Cloudflare has launched a closed beta of its OHTTP Gateway, a tool that decrypts Oblivious HTTP requests for websites. The gateway refuses to process requests that come through Cloudflare’s own services, like Cloudflare Workers or proxied hosts.

Oblivious HTTP, standardized as RFC 9458, splits a request into two parts. The client encrypts the request and sends it to a relay, which forwards it to the gateway. The relay sees the client’s IP address, but not the request content. The gateway decrypts the request and sends it to the website, but only sees the relay’s address.

A Privacy-Focused Design Decision

Cloudflare intentionally blocks requests from its own services. If a request passes through both the client-identifying hop and the decryption hop within Cloudflare, it defeats the protocol’s purpose. Authors Lara Schull and Akshat Mahajan emphasize that the model “requires that the relay and app server be operated by separate, non-colluding parties.”

For teams considering this technology, the relay component poses a practical challenge. Cloudflare does not provide a relay service, stating that relays are “simple” to set up on any infrastructure. The real challenge lies in committing to user privacy by not inspecting logs that contain client identifiers.

Operational and Adoption Challenges

Commenters raised operational concerns about Cloudflare‘s OHTTP Gateway. One question focused on whether Cloudflare’s WAF, which uses TLS fingerprinting, remains functional when OHTTP is enabled. If it does, this could imply that client metadata is processed by Cloudflare but not passed to the application server. Another issue centered on IP-based banning, with operators expressing the need to identify abusive behavior while respecting user privacy. The aggregation of data by a single entity was also noted, as it could reveal which sites an IP visited or which IPs accessed a specific customer, though this was still seen as an improvement over exposing source IPs and content.

Technical Details and Limitations

The OHTTP Gateway binds to a specific zone and listens at a fixed path, preventing customers from pointing it to another domain. Cloudflare manages the HPKE keys and serves public keys from the same path. Clients can fetch keys over a different IP address than the one used for requests.

The gateway supports both standard and chunked OHTTP, with chunked recommended for better performance. Cloudflare Access runs before decryption, allowing the relay to be authenticated with mutual TLS, static service credentials, or custom external logic.

Protection is limited to the network layer. Cloudflare states that OHTTP “provides privacy at the network level, and doesn’t touch the inner request body.” If identifying information is included in the request body, the gateway operator can still access it.

Discussion on Hacker News highlights the protocol’s narrow use case. It’s designed for stateless requests where preventing the gateway from correlating multiple requests from the same client is essential. This contrasts with a SOCKS5 proxy, which requires a new TCP connection for each request and lacks TLS session resumption.

One drawback is the lack of forward secrecy. If the gateway key is compromised, the relay can decrypt recorded traffic that used that key. However, compromising the client-relay and relay-gateway keys has less impact.

Cloudflare’s OHTTP Gateway resembles Tor but with a narrower scope. It requires a client that specifically supports the protocol and a known gateway, making it unsuitable for general browsing privacy. Instead, it’s tailored for app vendors seeking telemetry or lookup features without user identification.

Cloudflare cites Flo Health’s Anonymous Mode and Apple’s Private Cloud Compute as production examples. The gateway launches this fall, with a closed beta available now. It will be a paid add-on to a customer’s zone, though pricing is undisclosed.

Interested teams can register through a waitlist form, marking the next step in the protocol’s adoption and integration into real-world applications.