Oblivious HTTP

Oblivious HTTP (OHTTP) is a protocol for sending HTTP requests through an encrypted relay so no single party sees both the client identity and the request content. A client encrypts the request with the destination server's public key, sends the ciphertext through an intermediary relay, and the relay forwards the opaque payload to a gateway for decryption. The relay knows the client's IP address but not the request. The gateway sees the request but not the sender.

OHTTP defines three media types for the encrypted exchange: message/ohttp-req, message/ohttp-res, and application/ohttp-keys.

Usage

Traditional HTTPS protects request content from network observers but does not hide the client's identity from the destination server. The server always sees the client's IP address, and often correlates requests from the same client across sessions. For privacy- sensitive operations like telemetry collection, safe browsing lookups, and AI inference, this linkability is the core problem.

OHTTP solves the problem by splitting knowledge across two non-colluding parties. The relay (operated by one organization) strips the client's IP address and forwards the encrypted payload. The gateway (operated by a different organization) decrypts the payload and processes the request. Neither party holds both pieces of information. The architecture provides unlinkability: the gateway cannot determine whether two requests came from the same client.

The protocol operates at the HTTP request level, not the connection level. Each request is independently encrypted and routed, making OHTTP efficient for one-shot operations where a persistent tunnel is unnecessary.

Non-collusion requirement

The privacy guarantee depends on the relay and gateway being operated by separate, non-colluding entities. If the same organization controls both, the separation breaks down and the client's identity becomes linkable to the request content.

Architecture

OHTTP involves three roles and an optional fourth:

Client

The client constructs an HTTP request for the target resource, encodes the request in Binary HTTP format, and encrypts the encoded message using the gateway's public key. The client sends the resulting ciphertext as a POST request body to the relay. The client needs the gateway's key configuration before sending any request.

Oblivious relay

The relay receives the encrypted request from the client and forwards the opaque payload to the gateway. The relay sees the client's IP address and knows the gateway's address, but the request content is encrypted and unreadable. The relay strips or replaces any client-identifying metadata (IP address, connection identifiers) before forwarding.

The relay returns the gateway's encrypted response to the client without inspecting the content.

Oblivious gateway

The gateway holds the private key corresponding to the public key the client used for encryption. The gateway decrypts the request, forwards the plaintext HTTP request to the target resource, receives the response, encrypts the response, and returns the ciphertext to the relay.

The gateway sees the full HTTP request and response but does not know the client's IP address or any other identifying information. The gateway and the target resource are often co-located or operated by the same organization.

Target resource

The actual HTTP resource the client wants to reach. The target resource processes a standard HTTP request from the gateway and returns a standard HTTP response. The target resource is unaware OHTTP is in use.

Encryption

OHTTP uses Hybrid Public Key Encryption (HPKE) to protect request and response content. HPKE combines a key encapsulation mechanism (KEM) with authenticated encryption (AEAD), ensuring each request is independently encrypted with fresh keying material.

Key configuration

The gateway publishes a key configuration containing a key identifier, the KEM algorithm identifier, the public key, and one or more supported symmetric algorithm pairs (KDF and AEAD). Clients fetch this configuration before sending requests. The configuration is serialized using the application/ohttp-keys media type.

A key configuration contains:

Field	Size	Purpose
Key ID	8 bits	Identifies the gateway key
KEM ID	16 bits	Key encapsulation algorithm
Public key	Variable	Gateway's HPKE public key
Symmetric algorithms	Variable	KDF and AEAD pairs

Request encryption

The client selects a KEM and symmetric algorithm pair from the key configuration, generates a fresh HPKE context for each request, and encrypts the Binary HTTP-encoded request. The encrypted payload includes the encapsulated KEM shared secret, enabling the gateway to derive the decryption key.

Each request uses a new random HPKE context. Reusing a context across requests breaks the unlinkability guarantee.

Response encryption

The gateway derives a separate set of AEAD keys from the HPKE context's exported secret to encrypt the response. The response encryption uses a different key derivation path than the request, binding the response cryptographically to the specific request. Only the client holding the original HPKE context decrypts the response.

No forward secrecy

OHTTP does not provide forward secrecy during the lifetime of a key configuration. If the gateway's long-term private key is compromised, an attacker with recorded ciphertext recovers the plaintext of all requests encrypted with the affected key and all corresponding responses. Regular key rotation limits the window of exposure. TLS on the client-relay link provides a separate layer of protection for messages in transit.

Media types

OHTTP defines three media types for the encrypted message exchange:

message/ohttp-req

Carries the encrypted Binary HTTP request from the client through the relay to the gateway. The body is an opaque byte sequence containing the HPKE-encapsulated ciphertext. The relay forwards the body unchanged.

POST /gateway HTTP/1.1
Host: gateway.example.re
Content-Type: message/ohttp-req

message/ohttp-res

Carries the encrypted response from the gateway through the relay back to the client. The body contains AEAD-encrypted ciphertext derived from the request's HPKE context.

HTTP/1.1 200 OK
Content-Type: message/ohttp-res

application/ohttp-keys

Serializes the gateway's key configuration for client consumption. Clients fetch this resource to obtain the public key and supported algorithm parameters before sending encrypted requests.

GET /.well-known/ohttp-gateway HTTP/1.1
Host: gateway.example.re
Accept: application/ohttp-keys

Discovery

Clients need two pieces of information before sending an OHTTP request: the relay's address and the gateway's key configuration. The relay is typically pre-configured by the client application or operating system. The gateway's key configuration and location are discovered through DNS or a well-known URI.

SVCB DNS records

DNS Service Binding (SVCB) and HTTPS resource records advertise OHTTP support through the ohttp SvcParamKey (parameter number 8). The presence of this parameter in a DNS record signals the target service supports Oblivious HTTP access.

svc.example.re.  7200  IN HTTPS 1 . (
    alpn=h2 ohttp )

When marked as mandatory, the service is exclusively accessible through OHTTP:

svc.example.re.  7200  IN HTTPS 1 . (
    mandatory=ohttp ohttp )

Well-known URI

The gateway's key configuration is available at /.well-known/ohttp-gateway on the target service's host. Clients fetch this endpoint with a standard GET request to obtain the application/ohttp-keys payload.

Key rotation

Gateways rotate keys periodically. Clients refresh the key configuration regularly (daily is a common interval) to avoid using stale keys. A request encrypted with an expired key fails at the gateway, requiring the client to fetch a fresh configuration and retry.

Real-world deployment

OHTTP has broad adoption across major technology companies, with Cloudflare and Fastly operating the two primary relay services.

Apple Private Cloud Compute

Apple routes requests to its Private Cloud Compute (PCC) infrastructure through OHTTP relays operated by Cloudflare and Fastly. When Apple Intelligence processes a request requiring server-side computation, the device encrypts the request and sends the ciphertext through an OHTTP relay. The relay strips the device's IP address before forwarding to Apple's PCC gateway. Apple's servers process the AI request without knowing which device sent the query.

Apple also uses OHTTP for Enhanced Visual Search, applying the same relay-based architecture to anonymize image analysis requests.

Google Safe Browsing

Google operates an OHTTP gateway for the Safe Browsing API, enabling browsers to check URLs against malware and phishing lists without exposing browsing history to Google. The client encrypts the URL hash prefix, sends the ciphertext through a Fastly-operated relay, and the gateway performs the lookup. Google sees the query but not the client. Fastly sees the client but not the query.

Google Privacy Sandbox

Google selected Fastly as the OHTTP relay for the Privacy Sandbox k-anonymity server. Chrome sends encrypted requests through Fastly's relay to count ad interest groups without linking the count to individual browsers. The OHTTP layer prevents Google from associating k-anonymity queries with specific Chrome installations.

Mozilla Firefox telemetry

Mozilla uses OHTTP with Fastly's relay service to collect privacy-preserving browser telemetry. Firefox encrypts usage metrics and routes them through the relay before delivery to Mozilla's aggregation servers. Combined with the Distributed Aggregation Protocol (DAP), the system collects aggregate statistics without exposing individual user behavior. The telemetry pipeline uses the Glean SDK and strips all client identifiers before encryption.

Meta private processing

Meta uses OHTTP for private processing in Meta AI tools. WhatsApp message summarization requests pass through Fastly's OHTTP relay, hiding the requester's IP address from Meta's AI processing infrastructure.

Cloudflare Privacy Gateway

Cloudflare operates an OHTTP relay service called Privacy Gateway, available to any organization running an OHTTP gateway. Cloudflare also formally verified the privacy properties of the OHTTP protocol, mathematically proving the unlinkability guarantee holds under the stated assumptions.

Relationship to other protocols

Binary HTTP

OHTTP encrypts Binary HTTP messages, not text-based HTTP. Binary HTTP is a compact encoding of HTTP messages into a binary format suitable for encryption. The client encodes the HTTP request in binary form, then encrypts the binary representation. The gateway decrypts and decodes to recover the original HTTP message.

MASQUE

MASQUE (Multiplexed Application Substrate over QUIC Encryption) proxies UDP and IP traffic through HTTP. MASQUE operates at the connection level, creating persistent tunnels for all traffic between client and proxy. OHTTP operates at the individual request level, encrypting and routing single HTTP request-response pairs.

The two protocols serve different use cases. MASQUE suits always-on privacy tunnels (similar to a VPN), while OHTTP suits one-shot privacy-sensitive operations like API calls and telemetry. Both protocols are complementary and an HTTP server is able to function as a MASQUE proxy and an OHTTP relay simultaneously.

Apple iCloud Private Relay uses MASQUE for general web browsing privacy (proxying all Safari traffic through a two-hop relay), while using OHTTP for targeted operations like Private Cloud Compute requests.

Oblivious DNS over HTTPS

Oblivious DNS over HTTPS (ODoH) applies the same relay-based privacy architecture to DNS resolution. ODoH predates OHTTP and served as a proving ground for the three-party encryption model. Apple, Cloudflare, and Fastly collaborated on ODoH before extending the concept to general HTTP traffic with OHTTP.

Comparison with VPNs and Tor

OHTTP, VPNs, and Tor all hide a client's identity from a destination server, but they differ in scope, trust model, and performance.

VPNs encrypt all traffic between a client and a single exit point. The VPN provider sees both the client's IP address and the destination server address. A VPN shifts trust from the network operator to the VPN provider rather than eliminating trust entirely. VPN connections are persistent and cover all protocols and ports.

Tor routes traffic through three independently operated relays (guard, middle, exit), with each relay knowing only the previous and next hop. Tor provides strong anonymity through layered encryption and a large anonymity set, at the cost of significant latency from multiple round trips. Tor circuits persist across requests within a session.

OHTTP operates at the application layer on individual HTTP requests. Each request is independently encrypted and routed through exactly two parties (relay and gateway). OHTTP adds less latency than Tor because the path is shorter, and the relay-gateway split provides a well-defined trust boundary without requiring a large volunteer network. The trade-off is narrower scope: OHTTP protects specific HTTP transactions, not arbitrary network traffic.

Property	VPN	Tor	OHTTP
Layer	Network	Network	Application (HTTP)
Hops	1	3	2
Scope	All traffic	All traffic	Per-request
Trust model	Single provider	Distributed	Split (relay + gateway)
Latency	Low	High	Low
Persistent circuit	Yes	Yes (per session)	No

OHTTP is best suited for targeted, transactional privacy needs: DNS lookups, telemetry reporting, safe browsing checks, and API calls where per-request unlinkability matters more than full-session anonymity.

Example

Encrypted request flow

A client checks a URL against a safe browsing service without revealing the client's identity. The client fetches the gateway's key configuration, encrypts a Binary HTTP request, and sends the ciphertext through a relay.

Step 1: Fetch gateway key configuration

GET /.well-known/ohttp-gateway HTTP/1.1
Host: safebrowsing.example.re
Accept: application/ohttp-keys

The gateway returns the public key and supported algorithm parameters.

HTTP/1.1 200 OK
Content-Type: application/ohttp-keys

Step 2: Send encrypted request through relay

The client encrypts a Binary HTTP request using the gateway's public key and posts the ciphertext to the relay.

POST /relay HTTP/1.1
Host: relay.example.re
Content-Type: message/ohttp-req

<HPKE-encrypted Binary HTTP request>

The relay strips the client's IP address and forwards the opaque payload to the gateway.

Step 3: Gateway decrypts and processes

The gateway decrypts the request, forwards the plaintext to the target resource, encrypts the response, and returns the ciphertext through the relay.

HTTP/1.1 200 OK
Content-Type: message/ohttp-res

<AEAD-encrypted Binary HTTP response>

The client decrypts the response using the stored HPKE context.

DNS discovery

A DNS HTTPS record advertising OHTTP support for a service. The ohttp parameter signals Oblivious HTTP availability alongside HTTP/2 via ALPN.

safebrowsing.example.re. 7200 IN HTTPS 1 . (
    alpn=h2 ohttp )

Clients discovering this record fetch the key configuration from /.well-known/ohttp-gateway on the same host, then route encrypted requests through a pre-configured relay.

Takeaway

Oblivious HTTP separates client identity from request content by routing encrypted requests through a relay to a gateway. The relay knows the client but not the request. The gateway knows the request but not the client. Built on HPKE encryption and Binary HTTP encoding, OHTTP provides per-request unlinkability without persistent tunnels. Apple, Google, Mozilla, and Meta deploy OHTTP in production for AI inference, safe browsing, telemetry collection, and private messaging features, with Cloudflare and Fastly operating the primary relay infrastructure.