Cloudflare OHTTP Gateway: a managed option for privacy-preserving requests
Cloudflare has announced a closed beta of Cloudflare OHTTP Gateway, a self-service product for applications receiving Oblivious HTTP traffic. This is not a Cloudflare vulnerability announcement. The substantive change is a managed gateway option and a rename of the earlier Privacy Gateway product to Cloudflare OHTTP Relay, clarifying the two roles. For teams that want an application backend to receive useful requests without learning a user’s network identity, the announcement matters because it lowers operational work without removing the need to preserve OHTTP’s trust boundaries.
What OHTTP changes
In ordinary HTTP, an application server can see a client IP address, approximate location, and TLS fingerprint. Those signals can link requests to a person or device. OHTTP introduces a relay which sees client network identifiers but forwards encrypted content. A gateway decrypts the request, calls the application server, and encrypts the response. The backend can handle ordinary HTTP while not receiving the original client IP. HPKE protects the content between client and gateway, so the relay sees ciphertext rather than request plaintext. This is the intended double-blind model: no one party should see both network identity and request content.
Five details from the announcement
- The new Gateway is a closed beta. Customers join a waitlist and will enable a paid zone add-on.
- The standard endpoint is
/.well-known/ohttp-gateway. The service decrypts OHTTP, makes a subrequest to the app server, and encrypts the response; non-OHTTP traffic bypasses it. - Standard and chunked OHTTP are supported. Cloudflare recommends chunked OHTTP because incremental processing can improve performance.
- HPKE key management is handled by the service. Clients retrieve public key configuration with a GET request to the gateway endpoint.
- Cloudflare Access runs before decryption. mTLS, service credentials, and other Access policies can restrict traffic to trusted relays.
Choosing Relay or Gateway
Cloudflare describes its OHTTP Relay as the fit when application servers are outside Cloudflare and the customer runs its own gateway. The new Gateway is aimed at applications already behind Cloudflare CDN or Workers, and at services accepting OHTTP from a third-party relay, including an Apple Live Caller ID-style flow. This is not only a convenience choice. OHTTP requires the relay and application server to be separately operated and non-colluding. Cloudflare says the Gateway will refuse to decrypt requests from Cloudflare Workers or proxied Cloudflare hosts, preventing Cloudflare from seeing both client metadata at a relay and decrypted inner requests at a gateway.
Operational implications
OHTTP does not replace authentication, abuse prevention, or careful logging. The backend still needs a data-minimisation policy, and the pre-decryption Access policy must ensure that a purported relay is not an open entry point. Teams should also test end-to-end latency: the design adds hops and cryptographic work. Cloudflare uses its anycast edge to reduce relay-to-gateway latency, and a Cloudflare-hosted origin can avoid an extra external gateway-to-origin trip. Actual performance still depends on the relay, user geography, payload, and application behaviour.
Practical checklist
- Map which party sees IP metadata, plaintext, and logs; name the operator of relay and backend.
- Confirm relay and app-server placement preserves OHTTP’s separation of trust.
- Test public-key retrieval plus standard and chunked request paths.
- Apply a restrictive Access policy; prefer mTLS or service credentials for relays.
- Exercise key failures, relay failures, timeouts, limits, and observability without retaining unnecessary identifiers.
- Measure latency, capacity, and cost before putting sensitive application flows into production.
Conclusion
Cloudflare OHTTP Gateway gives privacy-oriented applications a managed way to separate network identity from request content. Its value is reduced implementation burden, not a shortcut around privacy architecture. Start with a precise trust-boundary diagram, trusted relay controls, and a measured pilot before production use.