Introducing the Cloudflare OHTTP Gateway

Expanding the reach of privacy-centric infrastructure

Date: October 2, 2026
Authors: Lara Schull and Akshat Mahajan
Read Time: $\approx 11$ minutes

Currently, the responsibility for maintaining digital privacy falls disproportionately on the end user. To shield themselves from targeted advertising or intrusive third-party trackers, individuals are often told to:

• Deploy a VPN.
• Disable browser cookies.
• Install various ad-blocking extensions.

Conversely, application developers often find themselves possessing more user data than is necessary or desirable. A standard client-server interaction leaves a digital breadcrumb trail, including the user's TLS fingerprint and their IP address.

To address this, Cloudflare is developing infrastructure that allows developers to integrate privacy directly into the application layer.

Understanding Oblivious HTTP (OHTTP)

OHTTP is an IETF standard designed to decouple a user's identity from their request. It allows a backend server to process an HTTP request without ever seeing the originating IP address.

The Core Principle: The separation of trust. By ensuring that no single entity possesses both the user's identity and the request content, privacy is mathematically and architecturally guaranteed.

How it Works: The Two-Hop Model

OHTTP utilizes two distinct roles to handle traffic:

1. The Relay: This entity blindly forwards encrypted packets. Its sole purpose is to strip away client identifiers before the request reaches the server.
2. The Gateway: This entity handles the cryptographic heavy lifting. It decapsulates the encrypted request and encapsulates the response so the app server can treat it like standard HTTP.

Expanding the Product Ecosystem

In 2022, Cloudflare introduced a product called Privacy Gateway Cloudflare OHTTP Relay. This tool allowed customers to implement privacy-first experiences. Notable examples include:

• Flo Health: Utilizing OHTTP for their Anonymous Mode.
• Apple: Using OHTTP within Private Cloud Compute to separate AI inference requests from specific user identities.

However, a gap existed: customers who already used Cloudflare to protect their servers could not use the Cloudflare Relay, as that would consolidate trust within a single provider, violating the OHTTP privacy model.

The New Offering: Cloudflare OHTTP Gateway

We are now launching the closed beta for the self-serve Cloudflare OHTTP Gateway. This is a paid add-on available for a user's zone, enabling OHTTP traffic reception with minimal configuration.

Choosing Your Architecture

Depending on your setup, you now have two primary paths to achieve the required separation of trust:

Decision Checklist:

• Are my app servers hosted on Cloudflare? $\rightarrow$ Use Cloudflare Gateway + 3rd Party Relay.
• Do I want to minimize operational overhead and latency? $\rightarrow$ Use Cloudflare Gateway.
• Am I capable of managing my own cryptographic gateway? $\rightarrow$ Use Cloudflare Relay + Self-Hosted Gateway.

The Rationale Behind the Gateway

Our decision to build the OHTTP Gateway stems from two primary observations:

1. Developer Demand: There is a significant appetite for "plug-and-play" privacy infrastructure. Developers want privacy by default, but the implementation hurdle is currently too high.
2. Operational Complexity: Building a performant gateway is difficult. Every extra hop adds latency, and the computational cost of encryption/decryption can degrade performance.

The Cloudflare Advantage

We are uniquely positioned to optimize this process. By leveraging our anycast network, the OHTTP Gateway runs on every server across our global edge.

$\text{Total Latency} = \text{Relay Hop} + \text{Gateway Hop} + \text{Origin Hop}$

By using our CDN, the Gateway can decrypt the request and resolve it to the app server on the same physical hardware (the same "metals"), effectively reducing the $\text{Origin Hop}$ to near zero.

OHTTP Primer: The Privacy Gap

In a traditional HTTP exchange, the server learns a great deal about the client. Because every packet requires a source IP to ensure delivery (much like a return address on a physical envelope), the server inherently knows where the request originated.

Furthermore, servers can perform "fingerprinting" by analyzing:

• Supported cipher suites.
• TLS versions.

These signals allow servers to link disparate requests to the same user, even if the user attempts to remain anonymous. OHTTP solves this by ensuring the entity that knows who the user is (the Relay) never knows what the user is asking, and the entity that knows what is being asked (the Gateway/Server) never knows who is asking.

Conceptual Request Flow

{
  "request": {
    "method": "GET",
    "path": "/api/data",
    "encrypted_payload": "0x7a2b...f31",
    "relay_id": "cloudflare-relay-01"
  },
  "privacy_status": "Oblivious"
}

By making these protocols easy to adopt, Cloudflare aims to raise the baseline of privacy across the entire internet.