In the modern digital landscape, the burden of maintaining online privacy falls disproportionately on end users. Everyday internet participants are routinely instructed to deploy virtual private networks, aggressively disable tracking cookies, or install third-party adblockers just to browse the web or use mobile applications without being relentlessly tracked. Meanwhile, standard client-server data exchanges inadvertently expose sensitive metadata to app developers, creating a persistent digital trail that includes client IP addresses and Transport Layer Security (TLS) fingerprints. For developers seeking to minimize data collection and respect user confidentiality, this high level of visibility is often an unwanted liability.
To help bridge this gap, infrastructure and security giant Cloudflare is expanding its privacy toolset with the introduction of the Cloudflare OHTTP Gateway. Designed to address the complexities of network-level privacy, the new gateway allows application backends to receive and process HTTP requests without ever seeing the originating user’s IP address. The service is built upon Oblivious HTTP (OHTTP), an established Internet Engineering Task Force (IETF) standard created specifically to decouple client identifiers from application payloads. Cloudflare has opened a closed beta for the self-serve product, inviting interested customers to join a waitlist ahead of a broader autumn rollout.
The Expansion of Cloudflare’s Privacy Suite
Underpinning the OHTTP architecture is a dual-hop model designed to isolate client data from application servers. In a typical OHTTP implementation, internet traffic routes through two independently operated entities: a relay and a gateway. The relay blindly forwards encrypted requests, effectively masking client identifiers from the application server. Concurrently, the gateway performs the heavy cryptographic lifting required to decapsulate incoming requests and encapsulate outgoing responses, allowing application servers to handle OHTTP traffic as if it were standard, plain HTTP. This strict separation of trust ensures that no single administrative entity ever gains visibility into both the client’s identity and the contents of their request.
Cloudflare first entered this space in 2022 with the launch of its OHTTP relay product, initially called Privacy Gateway and now officially renamed the Cloudflare OHTTP Relay. Over the past couple of years, this infrastructure has been adopted by major platform operators to power privacy-sensitive features. For instance, the popular health app Flo Health utilizes OHTTP to power its Anonymous Mode, while Apple’s Private Cloud Compute leverages the protocol to disassociate artificial intelligence inference requests from user identities.
However, a significant architectural limitation quickly became apparent for organizations already utilizing Cloudflare’s core web security and content delivery network. Customers protecting their application servers behind Cloudflare could not simultaneously utilize a Cloudflare-operated relay without violating OHTTP’s fundamental trust model, as Cloudflare would theoretically gain access to both metadata and decrypted request contents. To resolve this hurdle, developers needed a native OHTTP gateway option rather than a relay. By launching the new Cloudflare OHTTP Gateway alongside the existing relay network, Cloudflare is giving developers the flexibility to choose the component that best matches their specific infrastructure requirements.
Understanding the Mechanics of Oblivious HTTP
To appreciate the significance of the new gateway, it is helpful to examine the traditional vulnerabilities of standard client-server communication. When a client establishes a connection with an application server, the server naturally learns the client’s IP address because every data packet must carry a source identifier, functioning much like a return address on a traditional postal envelope. Furthermore, servers can easily fingerprint clients by analyzing negotiated parameters such as supported TLS versions or specific cryptographic cipher suites. These combined signals enable servers to link disparate requests across sessions, seamlessly tracking individual users over time.
OHTTP fundamentally disrupts this tracking mechanism by interposing a relay between the client and the destination server. When a client routes a request through an OHTTP relay, the server receiving the traffic sees only the relay’s network attributes rather than those of the end user. For example, a direct connection might expose a user’s residential IP address, autonomous system number, specific cipher suite, and precise geographic location down to the city level. In contrast, routing that same request through an OHTTP relay reveals only the relay’s IP address, data center ASN, and regional datacenter location.
Because thousands of distinct users route their traffic through shared relays, application servers lose the ability to distinguish individual activity or trace application actions back to a single device. Crucially, OHTTP transcends simple forwarding proxies by leveraging Hybrid Public Key Encryption (HPKE). This cryptographic wrapping ensures that requests and responses remain fully encrypted between the client and the application server. The relay sees only unreadable ciphertext, while the gateway handles the decryption layer, establishing a double-blind ecosystem where the relay knows who is connecting, the gateway and app server know what is being requested, and no single party ever sees both pieces of the puzzle.
Engineering a Scalable Gateway Architecture
Building and operating a secure, high-performance OHTTP gateway at scale has historically presented a steep engineering challenge for individual development teams. Proxying architectures inherently introduce latency by forcing network packets to traverse additional routing hops across the global internet. Furthermore, the computational overhead required to constantly decrypt incoming requests and encrypt outgoing responses can create severe performance bottlenecks for homegrown setups.
Cloudflare is uniquely positioned to mitigate these performance penalties through its extensive global anycast network. By deploying the new OHTTP Gateway across every server on its edge network, Cloudflare minimizes the physical distance and latency between relay and gateway nodes. For organizations already utilizing Cloudflare’s content delivery network, user requests can be decrypted directly by the local Gateway instance and resolved by application servers residing on the same underlying edge hardware, drastically reducing end-to-end latency.
To ensure frictionless adoption, the new gateway is integrated directly as a configurable feature within a customer’s domain zone. Clients send properly formatted OHTTP traffic to a designated well-known endpoint, and the system automatically scales capacity up or down to handle fluctuating loads without manual intervention. The infrastructure natively supports both standard OHTTP and chunked OHTTP protocols, with the latter recommended for optimal performance as it allows the network to process data streams incrementally.
Moreover, binding the gateway directly to a specific domain zone introduces robust security guardrails, protecting the infrastructure from being weaponized by malicious actors. The gateway automatically restricts incoming requests to authorized subdomains, preventing unauthorized clients from abusing the service to target external domains. Key management is similarly streamlined; the gateway fully automates the lifecycle of public HPKE key configurations, serving them directly through standard endpoint requests while allowing privacy-conscious clients to fetch keys over isolated network paths.
To enforce the strict separation of trust required by the protocol, Cloudflare has engineered hard safeguards into the platform. Recognizing that developers might accidentally compromise security by running both their relay and gateway within the same ecosystem, the new Cloudflare OHTTP Gateway is programmed to automatically refuse decryption requests originating from Cloudflare Workers or proxied hosts residing on the network. This technical enforcement guarantees that Cloudflare never simultaneously holds client identities and unencrypted request payloads.
Choosing Between Relay and Gateway Infrastructure
When designing privacy-preserving applications, developers must carefully evaluate whether a relay or a gateway is the appropriate architectural choice. Organizations that intend to host their application backends directly on Cloudflare—leveraging edge computing workers or content delivery optimizations—will find that the OHTTP Gateway aligns properly with protocol mandates. Conversely, developers building client applications that need to interface with third-party networks or SDKs, such as Apple’s LiveCallerID system, will typically rely on the gateway infrastructure to ingest traffic securely.
As Cloudflare prepares for the public rollout of the OHTTP Gateway, developers interested in evaluating the closed beta can register via the company’s waitlist portal. Implementing the architecture requires deploying a compliant OHTTP client alongside an independently operated relay. Because network-level encryption does not inspect inner payloads, developers must maintain strict internal disciplines to ensure sensitive personal identifiers like usernames or email addresses are excluded from request bodies. With these tools becoming more accessible, the internet infrastructure community is moving closer to making privacy-by-default a practical reality for developers worldwide.
Leave a Reply