Oblivious HTTP

OHTTP works well when you need to query sensitive data without revealing who's asking. Common use cases:

• Safe browsing checks (verify URLs against blocklists without exposing browsing history)
• Private telemetry (collect aggregate metrics without identifying individual users)
• AI/ML inference (send queries to ML services without linking requests to identities)
• Key transparency (look up public keys without revealing communication patterns)

If your use case involves per-request unlinkability and you trust separate relay/gateway operators, OHTTP is a good fit.

OHTTP uses HPKE (RFC 9180), Hybrid Public Key Encryption. Each request generates a fresh ephemeral keypair, which provides unlinkability (ciphertexts from the same client are computationally indistinguishable) and confidentiality (only the gateway can decrypt requests).

One caveat: OHTTP does not provide forward secrecy against gateway key compromise. If the gateway's private key leaks, recorded ciphertexts can be decrypted.

The fastest path depends on your deployment model. Cloudflare and Fastly offer hosted OHTTP relays, so you only need to run a gateway. If you want to self-host everything, use ohttp-ts, ohttp-go, or ohttp (Rust) and partner with another organization for the relay or gateway role.

Check out the code examples to see the full client/relay/gateway flow.

For privacy guarantees, the relay and gateway must be operated by different, non-colluding parties. Cloudflare, Fastly, and oblivious.network operate public OHTTP infrastructure. You can also deploy your own using the implementations above and partner with another organization for the complementary role.

Gateways publish their public key configuration in a few ways. The standard approach is the well-known URI (/.well-known/ohttp-gateway). For zero-RTT discovery, you can encode the key config in DNS SVCB/HTTPS records. Closed deployments often distribute keys out-of-band via configuration.

OHTTP protects against passive observers but has limitations. If the relay and gateway collude, they can correlate your IP with your requests. OHTTP doesn't pad messages, so timing and size patterns can leak information. And each OHTTP request is independent: session-based correlation (cookies, login) still identifies you to the target.

OHTTP is designed for unlinkability, not anonymity. It hides who made a specific request, not that requests were made.

A few resources worth reading:

• Mozilla's OHTTP explainer is a good starting point with clear diagrams.
• http.dev/ohttp goes deeper on architecture and real-world deployments.
• Cloudflare's formal verification proves OHTTP's privacy properties using Tamarin.