Skip to content

CONCEPT Cited by 2 sources

Oblivious HTTP (OHTTP)

Definition

Oblivious HTTP (OHTTP; RFC 9458) is a protocol that allows a client to send an HTTP request to a gateway such that no single party learns both the client identity (IP address) AND the request contents.

The architecture partitions trust across two independent parties:

  • Relay — sees the client's IP address but cannot read the inner HTTP request (it receives an HPKE-encrypted blob addressed to the gateway).
  • Gateway — sees the inner HTTP request but not the client IP (the relay has forwarded the request on the client's behalf).

As long as the relay and gateway are operated by different parties that do not collude, neither can link a specific user to a specific request. This is the two-party unlinkability property that OHTTP provides.

Why OHTTP matters for non-targetability

If the provider runs both the gateway and the server fleet (e.g. a TEE-based inference cluster), a targeted-hardware attack against a specific user would be trivial if the provider knew who was calling: route user U to compromised host H, read U's plaintext on H. OHTTP destroys the routing capability by stripping the caller's IP at a third-party relay before the provider sees the request. Combined with application-layer authentication via anonymous credentials (so the gateway can validate the caller's eligibility without learning their identity), the provider cannot map a request back to a specific user even if it wanted to.

Canonical wiki instance: WhatsApp Private Processing

The 2025-04-30 Meta post names OHTTP verbatim as the wire-session primitive, phase 3 of the six-phase flow:

"Private Processing establishes an OHTTP connection from the user's device to a Meta gateway via a third-party relay which hides requester IP from Meta and WhatsApp."

Phase 2 fetches HPKE public keys "from a third-party CDN" — these are the gateway's public keys that the device uses to encrypt the inner request. Phase 1 obtains anonymous credentials for the inner-layer authentication, so the gateway can validate the caller without re-identifying them.

What OHTTP does not defend against

  • Relay–gateway collusion — if both parties cooperate, they can re-link IP to request.
  • Traffic-analysis attacks — timing, volume, cadence can still correlate.
  • Application-layer re-identification — if the inner request carries an account token, the gateway re-learns the user. Private Processing specifically avoids this with ACS anonymous credentials.
  • Content confidentiality from the gateway — the gateway sees plaintext of the inner request; OHTTP does not E2EE the content all the way to the origin. In Private Processing, a further E2EE layer (the ephemeral key the client shares with the attested CVM) sits inside OHTTP, so Meta's own gateway also cannot read the request body.

Seen in

Last updated · 608 distilled / 1,858 read