Cloudflare launches closed beta of managed OHTTP Gateway

A managed path to private HTTP requests

Cloudflare has launched the closed beta of its OHTTP Gateway, a managed service based on an IETF standard that lets application backends receive HTTP requests without seeing users' IP addresses. OHTTP separates client-facing privacy from request processing through two independently operated components. A relay forwards encrypted requests while hiding client identifiers from the application server. A gateway decapsulates requests and encapsulates responses, allowing the server to handle plain HTTP.

The design is intended to prevent any single party from seeing both client identifiers and request contents. The relay can see identifiers such as an IP address or TLS fingerprint, but not the plaintext request contents. The gateway and application server can process the contents without learning the end user's network identity. Cloudflare says the Gateway is aimed particularly at applications already hosted behind its CDN or Workers, as well as services receiving traffic from a third-party relay. The closed beta is self-service, while a paid zone add-on is planned for this fall.

Relay and gateway options

Cloudflare launched its OHTTP relay product, Privacy Gateway, in 2022 and is renaming it Cloudflare OHTTP Relay. Developers with application servers hosted outside Cloudflare can use the Cloudflare relay and run their own gateway. Those already protecting servers through Cloudflare can use the new managed Gateway with an independently operated third-party relay. This preserves OHTTP's required separation of trust.

Cloudflare cites Flo Health's Anonymous Mode and Apple's Private Cloud Compute as existing uses of OHTTP. It also lists receiving requests from an external relay, including traffic associated with Apple's LiveCallerID SDK, as a use case for the Gateway.

Built for edge deployment

The service is deployed across Cloudflare's global edge network and scales automatically. Cloudflare says its anycast architecture minimizes relay-to-gateway latency, while use with its CDN can reduce gateway-to-origin latency. The Gateway supports standard and chunked OHTTP, with chunked processing recommended for better performance. It can be enabled on a zone and reached at the /.well-known/ohttp-gateway path. The service processes OHTTP requests and returns encrypted responses, while non-OHTTP traffic continues to the origin without using the Gateway.

Cloudflare manages the HPKE keys required for clients to encrypt requests and serves public key configurations. Cloudflare Access runs before decryption and can authenticate traffic with mutual TLS, static service credentials or external logic. Zone binding helps prevent the Gateway from being used to target unrelated domains. To avoid violating OHTTP's privacy model, the Gateway will not decrypt requests from Cloudflare Workers or proxied hosts on Cloudflare.

Deployment requirements and limits

Developers seeking the managed Gateway still need to implement an OHTTP client and bring their own independently operated relay. Cloudflare says this separation allows a relay provider to make a verifiable promise that it will not inspect client identifier logs, reducing the risk of correlating users with decrypted requests. OHTTP protects network identifiers, but it does not alter the inner request body. Developers therefore must avoid placing personal identifiers such as email addresses or usernames there. Cloudflare also provides its pvcli client for testing and debugging live OHTTP deployments.