Individual users shoulder most of the responsibility for protecting their online privacy today. To ward off tracking and targeted advertising, they're told to deploy VPNs, manage cookies carefully, or run ad blockers. On the flip side, application developers often gain visibility into user behavior they would prefer not to have: standard client-server interactions expose sensitive details such as the user's IP address and TLS fingerprint. Cloudflare is addressing this imbalance by building infrastructure that embeds privacy directly into applications.
Oblivious HTTP (OHTTP), an IETF standard, enables application backends to process HTTP requests while remaining blind to user IP addresses. Cloudflare is rolling out the Cloudflare OHTTP Gateway this fall as a paid add-on to customer zones, allowing developers to begin handling OHTTP traffic with minimal setup. Interested parties can join the waitlist through a registration form.
Expanding our OHTTP product suite
OHTTP routes requests through two separate, independently-operated components: a relay and a gateway. The relay forwards encrypted requests without revealing client identifiers to the application server. The gateway performs the cryptographic operations needed to decrypt incoming requests and encrypt responses, allowing application servers to handle OHTTP as standard HTTP. This architectural separation of trust is essential: it guarantees that no single entity observes both client identifiers and request contents simultaneously.
Cloudflare introduced its OHTTP relay product, Privacy Gateway, in 2022. The service has enabled customers to deliver more privacy-conscious experiences to their users. Flo Health integrated OHTTP into its app's Anonymous Mode, and Apple's Private Cloud Compute leverages OHTTP to disconnect AI inference requests from user identities. However, customers already running their application servers on Cloudflare's infrastructure faced a constraint: they could not use a Cloudflare-operated relay because doing so would compromise OHTTP's privacy guarantees. Those customers needed a gateway instead.
Operating a secure, high-performance OHTTP gateway at scale has proven challenging based on Cloudflare's experience running relays. The company is now launching a closed beta for its self-serve Cloudflare OHTTP Gateway. Simultaneously, it is renaming its "Privacy Gateway" product to "Cloudflare OHTTP Relay" to provide clearer product distinction.
Customers seeking an OHTTP setup with proper separation of trust now have two paths forward:
- Deploy Cloudflare's OHTTP Relay (formerly Cloudflare Privacy Gateway) while operating your own gateway. This approach suits applications hosted outside Cloudflare where you have the capability to run your own OHTTP gateway.
- Use Cloudflare's new OHTTP Gateway paired with a third-party relay. This option works best if your application servers already sit behind Cloudflare (on the CDN or Workers), if you're accepting OHTTP requests from external sources like Apple's LiveCallerID, or if you prefer a managed gateway to reduce latency and operational burden.
Cloudflare aims to raise privacy standards across the internet and believes protocols like OHTTP can achieve this goal if adoption becomes straightforward. The company's objective has always been to broaden its OHTTP offerings and make its trusted privacy infrastructure available to larger portions of the internet.
Why we built the Cloudflare OHTTP Gateway
Since launching its OHTTP Relay product, Cloudflare has identified several key trends.
Developer interest in accessible, usable privacy infrastructure continues to grow. Creators of privacy-focused applications want to embed network privacy into their products as a default feature, yet the process remains more difficult than it should be.
Building and running an OHTTP gateway presents genuine operational challenges for customers. Any proxying design introduces latency because traffic must traverse additional hops across the internet. When combined with the computational cost of decrypting requests and encrypting responses, a self-managed OHTTP setup can incur substantial latency penalties. Cloudflare is well-suited to solve this problem: the infrastructure components that power fast, reliable privacy services like 1.1.1.1 and iCloud Private Relay provide the foundation for an effective OHTTP gateway. Cloudflare's anycast architecture means the OHTTP Gateway runs on every edge server in its global network, reducing latency on relay-to-gateway paths. When customers use Cloudflare's CDN, user requests can be decrypted by the Gateway and fulfilled by application servers on the same Cloudflare hardware, eliminating gateway-to-origin latency.
OHTTP's privacy model requires that the relay and application server operate independently and do not collude. Cloudflare wants to give customers the widest possible range of options for their privacy infrastructure. Previously, developers whose application servers ran behind Cloudflare could not use Cloudflare's OHTTP Relay because Cloudflare would simultaneously see both client metadata and decrypted request contents, violating OHTTP's privacy model. Now, developers can decide whether a Cloudflare OHTTP Relay or Gateway better matches their architecture.
A primer on OHTTP
Standard client-to-server communication exposes information about the client. When a client and application server exchange data, the server learns the client's IP address because each packet carries a source IP label, similar to a "from" address on an envelope. Application servers can also derive a client "fingerprint" from characteristics such as supported TLS versions or cipher suites. These signals allow servers to correlate multiple requests to the same user.
Consider a scenario where an application should know very little about its users. Flo Health, for instance, wanted to create an Anonymous Mode allowing users to access personal health information without linking it to identifiable user data.
OHTTP introduces a "relay" proxy that sits between client and application server, masking the client's identity from the server. The relay observes client identifiers such as IP address and TLS fingerprint but removes them before forwarding requests. This prevents application servers from correlating multiple requests to a single user and stops request contents from being tied to the user's IP address.
A typical client-server exchange might expose the following client information:
- ipAddress: 192.0.2.33 # the client's IP address - ASN: 7922 - tlsCipher: AEAD-CHACHA20-POLY1305-SHA256 # potentially unique - tlsVersion: TLSv1.3 - Country: US - Region: California # the client's location - City: Campbell
When a request travels through an OHTTP relay first, the application server receiving it sees only the relay's information:
- ipAddress: 128.62.37.13 # the relay's IP address & fingerprint - ASN: 18 - tlsCipher: AEAD-AES-128-GCM-SHA256 - tlsVersion: TLSv1.3 - Country: US - Region: Texas # the relay's location - City: Austin
As a result, the application server cannot determine the end user's location or TLS fingerprint for each request. If numerous users send requests through the same relay, the server cannot distinguish between them, severely limiting its ability to trace activity back to individual users. This establishes a robust privacy boundary.
What sets OHTTP apart from a simple forwarding proxy is the encryption of data between client and application server. Requests and responses are encapsulated using Hybrid Public Key Encryption (HPKE), ensuring that only the client and application server can read plaintext while the relay sees only encrypted gibberish. A "gateway" positioned between relay and server handles all cryptographic operations—decapsulating requests, encapsulating responses—while the application server processes only plain HTTP.
This creates a "double-blind" privacy model: the relay sees only client identifiers; the gateway and application server see only request contents; no party sees both.
How we built the OHTTP Gateway
In developing its OHTTP gateway-as-a-service, Cloudflare aimed to extend its secure, high-performance privacy infrastructure to more of the internet. Performance and straightforward onboarding were paramount. The company built its Gateway as a flexible service distributed across its global network. With just a few clicks, customers can activate the Gateway on their zone and begin sending OHTTP requests to https://your-zone.com/.well-known/ohttp-gateway. The service scales automatically, eliminating capacity concerns.
Several additional user requirements shaped the design, drawn from challenges Cloudflare observed when OHTTP Relay customers operated their own gateways.
First, Cloudflare wanted to minimize OHTTP complexity for application servers. Developers should be able to accept OHTTP while continuing to handle regular HTTP traffic if desired. The Gateway was designed as a zone feature where clients send properly-formatted OHTTP requests to a /.well-known/ohttp-gateway endpoint on the zone. Both standard and chunked OHTTP are supported—chunked OHTTP is recommended for superior performance because it allows incremental request processing.
The Gateway service intercepts each request, decrypts it, issues a subrequest to the application server, and returns an encrypted response to the client. Non-OHTTP requests pass through to the server without Gateway involvement.
Binding the Gateway to a zone also lets Cloudflare defend it against abuse. A client sending requests to example.com may target foo.example.com or bar.example.com, but not wikipedia.com. This prevents unauthorized clients from using a zone to attack other domains, without requiring customer intervention.
Second, seamless key management is vital. Gateways must maintain a public HPKE key configuration to allow clients to encrypt requests, but secure key management is challenging. Cloudflare designed the Gateway to fully manage all keys for customers and serve public keys as responses to GET requests to /.well-known/ohttp-gateway. For enhanced privacy, clients can download keys over a different IP than they use for gateway requests.
Third, gateways must authenticate relays. Since the Gateway intentionally knows little about the client sending a request, it relies on the relay to authenticate clients and forward traffic responsibly. Ensuring only trusted relays can send traffic to the gateway required a solution.
Cloudflare designed the Gateway to run Cloudflare Access, its zero trust network access product, before requests are decrypted. This enables customers to apply any standard Access policies to authenticate incoming traffic and protect the Gateway from abuse. Options include mutual TLS, static service credentials, and custom external logic.
Finally, recognizing that mistakes happen, Cloudflare anticipated customers might inadvertently break OHTTP's privacy model by running both relay and gateway on Cloudflare. To preserve OHTTP's separation of trust and prevent Cloudflare from seeing both client identities and decrypted inner requests, the Gateway refuses to decrypt requests sent from Cloudflare Workers or from proxied hosts on Cloudflare.
When is the OHTTP Gateway a better fit than the OHTTP Relay?
For customers considering Cloudflare's OHTTP product suite, deciding between the OHTTP Gateway and OHTTP Relay involves two key factors.
First, do you want your application servers on Cloudflare—behind the CDN or built on Workers? If yes, the OHTTP Gateway is the better choice to maintain OHTTP's privacy model.
Second, what is your use case? If you need to receive OHTTP requests from a third-party client and relay—such as when using Apple's LiveCallerID SDK—the OHTTP Gateway is likely the superior solution.
Getting started
Customers with feature requests or those wishing to join the waitlist for product launch notifications can register through a signup form.
Implementation requires building an OHTTP client. Resources like ohttp.info and Cloudflare's sample client library provide guidance. One important consideration: OHTTP provides privacy at the network level and does not modify the inner request body. Preserving user privacy depends on developers avoiding identifying information—such as email addresses or usernames—in the request body.
Next, customers must provide their own relay. Relays can run on any infrastructure provider and are straightforward to implement; sample code is available. The challenge—and reason some might prefer a dedicated OHTTP relay provider—is verifiably assuring users that client identifier logs will not be inspected. Otherwise, relays could correlate clients with decrypted requests at application servers.
Once OHTTP deployment is operational, Cloudflare's pvcli client assists with testing and debugging. Cloudflare is committed to bringing accessible privacy infrastructure to developers everywhere and welcomes inquiries from those interested in testing the new OHTTP Gateway and advancing privacy standards online.