Skip to content

PATTERN Cited by 1 source

Third-party OHTTP relay for unlinkability

Pattern

Route client traffic to your gateway via an OHTTP relay operated by a party independent of the service provider, so that:

  • The relay sees the client IP but not the inner request (the inner request is HPKE-encrypted to the gateway's public key).
  • The gateway sees the inner request but not the client IP (the relay forwarded it).

No single entity on the request path can correlate who is calling with what they are calling for. This is the core two-party unlinkability property of OHTTP, and it is load-bearing for non-targetability in services like WhatsApp Private Processing where the same provider runs both the gateway and the downstream TEE fleet.

Problem

If the provider gateway can see both "who is calling" (IP / account token) and "where the request is routed to" (which TEE host), then a compromised operator (or insider) can target a specific user by steering their request to a specific malicious or watched host. Confidentiality inside the TEE does not help if routing selection is already user-aware.

Solution

  1. Partition request knowledge across independent parties.
  2. Encrypt the inner request with HPKE to the gateway's public key before it leaves the client. The relay only sees an opaque blob + destination.
  3. Strip the client IP at the relay. The gateway only sees the relay's IP.
  4. Authenticate inside the tunnel with anonymous credentials, not with identity-bearing tokens. Otherwise the gateway can re-identify the caller from auth headers and defeat the IP-stripping.
  5. Operate the relay and the gateway separately — different organisations, different legal jurisdictions ideally — so they cannot trivially collude.

Canonical wiki instance

The 2025-04-30 Meta post describes the realisation verbatim as wire-session phase 3:

"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."

and, binding the pattern to non-targetability:

"Private Processing implements the OHTTP protocol to establish a secure session with Meta routing layers. This ensures that Meta and WhatsApp do not know which user is connecting to what CVM."

Why "third-party" is load-bearing

If the relay is operated by the same party as the gateway, the pattern collapses: one organisation can correlate IP + request at its own infrastructure boundary, whether or not the protocol technically separates them. The operational independence of the relay from the provider is what makes the property defensible against the provider as an adversary. Provider + relay + transparency-log operators form a partitioned trust model; compromising the pattern requires compromising all three.

Failure modes

  • Relay–gateway collusion. If they share information, non-targetability collapses. Defence: pick a relay operator with contractual + legal incentives against collusion (and ideally a different jurisdiction).
  • Identity-bearing auth tokens inside the tunnel. Re-identify the caller at the gateway, defeat the IP-strip. Defence: anonymous credentials.
  • Traffic-analysis correlation. Timing, volume, cadence can re-link IP to request. Defence: padding, batching, jitter.
  • Single-relay bottleneck. Availability + censorship risk. Defence: multiple relays, client-side selection.
  • Metadata leakage via cookies / headers. Defence: strip client-originated metadata at relay before forwarding.

Seen in

Last updated · 319 distilled / 1,201 read