Oblivious HTTP (OHTTP): Privacy-Preserving Request Relay at CDN Edge

Content delivery networks have always operated on a fundamental trade-off: the closer your processing logic sits to the user, the more you inherently know about that user. Every edge node that terminates a TLS connection learns the client IP address, the requested URL, timing patterns, and device fingerprints. For an industry built on performance through proximity, the privacy implications of edge processing have been an uncomfortable undercurrent since CDNs became critical internet infrastructure.

Oblivious HTTP (OHTTP), standardized in RFC 9458, introduces a cryptographic architecture that severs the link between client identity and request content at the protocol level. It enables CDN operators to process, cache, and respond to requests without ever knowing who made them—not through policy promises, but through mathematical guarantees. This article examines OHTTP’s architecture, its integration with CDN edge infrastructure, the performance implications at scale, and the privacy-sensitive use cases driving adoption.

The Privacy Gap in Traditional CDN Architecture

In a standard CDN request flow, the edge server terminates the TLS connection from the client. At that point, the edge node possesses:

• The client’s IP address (from the TCP connection)
• The full HTTP request including URL, headers, cookies, and body
• TLS metadata including SNI (Server Name Indication), client certificate if present, and cipher negotiation
• Timing information that can be correlated across requests to build browsing profiles

Even with zero trust security policies, the CDN operator is a trusted party with full visibility into user behavior. For privacy-regulated industries (healthcare under HIPAA, finance under GDPR, government under FISMA), this creates compliance complexity. The CDN operator becomes a data processor with access to personally identifiable information, requiring data processing agreements, audit trails, and geographic data residency controls.

OHTTP eliminates this class of problem by making it cryptographically impossible for the CDN to correlate requests with identities.

OHTTP Architecture: Separating Identity from Intent

OHTTP introduces three roles that split the information traditionally held by a single CDN edge server across two independent parties:

The Client

The client obtains the gateway’s public key (typically via a DNS HTTPS record or a well-known endpoint), encrypts its HTTP request using Hybrid Public Key Encryption (HPKE), and sends the resulting opaque capsule to the relay. The client never communicates directly with the gateway.

The Relay

The relay receives the OHTTP capsule from the client over a standard HTTPS connection. It sees the client’s IP address (from the TCP connection) but cannot decrypt the capsule because it does not hold the gateway’s private key. The relay forwards the capsule to the gateway, stripping the client IP and replacing it with a relay-assigned identifier. Importantly, the relay and gateway must be operated by different, non-colluding entities for the privacy guarantee to hold.

The Gateway (CDN Edge)

The CDN edge node acts as the OHTTP gateway. It holds the private key corresponding to the gateway public key distributed to clients. When it receives a forwarded capsule from the relay, it decrypts the HPKE-encrypted HTTP request, processes it (including cache lookups, edge computation, and origin fetches), encrypts the response back to the client using the HPKE session key, and returns the encrypted response capsule through the relay.

HPKE: The Cryptographic Foundation

OHTTP relies on Hybrid Public Key Encryption (RFC 9180) for its request encapsulation. HPKE combines an asymmetric key exchange (typically X25519 or P-256) with an AEAD symmetric cipher (AES-128-GCM or ChaCha20-Poly1305) to produce a one-shot encryption scheme. Each OHTTP request generates a fresh ephemeral key pair, ensuring that two requests from the same client to the same gateway produce cryptographically unlinkable capsules.

This unlinkability property is what makes OHTTP superior to simpler proxy-based privacy solutions. Even if an adversary observes all relay-to-gateway traffic, they cannot determine whether two capsules originated from the same client. Combined with the relay stripping client IP addresses, this creates a strong anonymity set limited only by the number of clients using the same relay.

# OHTTP capsule structure (simplified)
# Client constructs:
encapsulated_request = HPKE.Seal(
    gateway_public_key,
    info = "message/bhttp request",
    aad = key_id || kem_id || kdf_id || aead_id,
    plaintext = Binary HTTP encoded request
)

# Wire format:
# [key_id (1B)] [kem_id (2B)] [kdf_id (2B)] [aead_id (2B)]
# [enc (32B for X25519)] [encrypted_request (variable)]

# Gateway decrypts:
request = HPKE.Open(
    gateway_private_key,
    enc = capsule.enc,
    info = "message/bhttp request",
    aad = capsule.header,
    ciphertext = capsule.encrypted_request
)

CDN Integration Patterns

Deploying OHTTP at CDN scale requires addressing several architectural challenges that do not exist in smaller deployments.

Key Distribution and Rotation

The gateway public key must be discoverable by clients before they can create OHTTP capsules. CDN operators publish this key through DNS HTTPS resource records (SVCB/HTTPS RR with the “ohttp” SvcParamKey) and through a .well-known/ohttp-gateway endpoint. Key rotation must be coordinated across all edge nodes simultaneously to prevent request failures when a client uses a newly rotated key that has not propagated to all PoPs.

Cache Architecture Adaptation

Standard CDN caching strategies rely on inspecting the URL and headers of incoming requests to determine cache eligibility. With OHTTP, the request is opaque until the gateway decrypts it. This means caching decisions move entirely post-decryption. The gateway decrypts the request, checks the local cache using standard cache key computation, and serves from cache if possible. Cache population works normally since the decrypted request is a standard HTTP message.

The practical impact is that OHTTP requests cannot benefit from the CDN’s connection coalescing or request collapsing optimizations that operate on encrypted connections, since the CDN cannot identify identical requests until decryption.

Geographic Routing Without Client IP

CDN DNS-based routing and anycast steering use client IP geolocation to direct requests to the nearest edge PoP. With OHTTP, the gateway receives requests from the relay, not the client. The relay’s location becomes the routing signal. To mitigate this, OHTTP deployments typically use relay providers with geographically distributed infrastructure, and the relay selects the geographically nearest gateway PoP based on its own location. This introduces a potential latency penalty when the client and relay are in different regions.

Performance Characteristics

OHTTP performance overhead comes from three sources: the additional network hop through the relay, the HPKE cryptographic operations, and the Binary HTTP encoding.

The relay hop is the dominant latency source. A well-placed relay adds 5 to 15 milliseconds to round-trip time. A poorly placed relay (geographically distant from both client and gateway) can add 50 milliseconds or more. CDN operators deploying OHTTP should partner with relay operators that have extensive PoP coverage, or operate relay infrastructure themselves (though this undermines the non-collusion requirement unless organizationally separated).

HPKE cryptographic overhead is negligible at CDN scale. X25519 key exchange plus AES-128-GCM encryption adds approximately 0.05 milliseconds per request. On an edge server handling 50,000 requests per second, this is 2.5 CPU-seconds of overhead—well within the margin already consumed by TLS termination.

Binary HTTP (RFC 9292) encoding adds a small serialization cost. The binary format is more compact than text HTTP/1.1 but requires encoding and decoding steps. The encoding is linear in message size and adds negligible overhead for typical API requests (under 10 KB).

Privacy-Sensitive Use Cases Driving Adoption

DNS Privacy (Oblivious DoH)

The first major OHTTP deployment is Oblivious DNS over HTTPS (ODoH), where DNS queries are encapsulated in OHTTP to prevent the DNS resolver from learning the client IP. Apple iCloud Private Relay uses this architecture with Cloudflare as the gateway and Apple-operated relays.

Telemetry Collection

CDN operators can use OHTTP to collect performance telemetry (Core Web Vitals, error rates, resource timing) from clients without associating measurements with user identities. The gateway aggregates anonymized telemetry data that preserves statistical value without creating individual browsing profiles.

Privacy-Preserving APIs

APIs handling sensitive queries (health information lookups, financial data, location services) benefit from OHTTP by ensuring the CDN edge that processes the request cannot link the query content to a specific user. This is particularly valuable for API gateway deployments at CDN edge where the CDN operator is a third party relative to both the API consumer and provider.

Ad Measurement Without Tracking

OHTTP enables privacy-preserving ad conversion measurement where the CDN gateway processes attribution reports without knowing which user generated them. Combined with differential privacy techniques applied at the gateway, this supports aggregate measurement without individual tracking.

Operational Considerations

CDN operators deploying OHTTP must address several operational realities that differ from standard edge deployments.

Abuse prevention becomes harder without client IP visibility. Rate limiting must shift from per-IP to per-relay or per-capsule-key strategies. The gateway can negotiate with the relay for coarse abuse signals (relay-level rate limits, relay-originated abuse reports) without exposing individual client identities.

Logging and debugging changes fundamentally. Access logs at the gateway contain request details without client identifiers. Troubleshooting user-reported issues requires correlation through the relay, which only the relay operator can perform. CDN operators should build debugging workflows that work with anonymized request logs.

Key compromise recovery is critical. If the gateway private key is compromised, all OHTTP capsules encrypted with the corresponding public key can be decrypted. Rapid key rotation and forward-secrecy mechanisms (rotating keys on short intervals, similar to post-quantum key management) limit the window of exposure.

OHTTP represents a fundamental shift in CDN architecture: from trusting the CDN operator with full request visibility to cryptographically limiting what the CDN can observe. As privacy regulations tighten globally and users demand verifiable privacy guarantees, OHTTP will evolve from a niche deployment to a standard CDN capability.