Most privacy tools encrypt the contents of a request. Oblivious HTTP attacks a different problem: making sure the server that learns your IP address is never the same server that reads your request. Standardized as RFC 9458 in 2024, it is a small, sharp tool for a specific class of telemetry and lookup traffic.
When your phone reports a crash, checks a URL against a safe-browsing list, or sends an anonymized usage metric, two facts travel together by default: the contents of that request, and the network address it came from. A single server on the receiving end sees both. Over millions of requests, that pairing is enough to build a profile keyed to you, even when each individual message looks innocuous.
Oblivious HTTP, or OHTTP, exists to break that pairing. The design goal is narrow and worth stating precisely: ensure that no single party sees both the client's identity and the client's message. It does this not with heavy anonymity machinery but with two cooperating servers and one layer of public-key encryption.
The Two-Server Split
OHTTP introduces four roles. The client wants to send a request. The oblivious relay receives that request and forwards it. The oblivious gateway decrypts the request and passes it to the target resource that actually answers it. The relay and gateway are operated by different organizations that are trusted not to collude.
The mechanism rests on a clean division of knowledge:
- The relay sees your IP address, because you connect to it directly. It does not see your request, because the request is encrypted to the gateway's public key, which the relay does not hold.
- The gateway sees your request, because it can decrypt it. It does not see your IP address, because the connection it receives comes from the relay, not from you.
Neither server alone can link a person to a query. The privacy property holds as long as the two operators do not combine their logs. That non-collusion assumption is the load-bearing trust in the whole design, and it is why deployments deliberately put the relay and gateway under separate administrative control.
The relay knows who you are but not what you said. The gateway knows what you said but not who you are. Privacy fails only if these two parties merge their records.
How the Encryption Actually Works
OHTTP does not invent its own cryptography. The encapsulation is built on HPKE (Hybrid Public Key Encryption, RFC 9180), the same modern primitive used in TLS Encrypted Client Hello and the Message Layer Security protocol.
The flow looks like this. The gateway publishes a key configuration: an HPKE public key plus the identifiers for the key derivation function and the authenticated-encryption algorithm it expects. The client fetches this configuration, then uses HPKE to encapsulate its binary HTTP request into an encrypted blob carried with the media type message/ohttp-req. The client sends that blob to the relay over an ordinary HTTPS connection.
The relay forwards the blob to the gateway. The gateway decrypts it, recovers the inner request, and hands it to the target. The response travels back through the same path, encrypted with a key derived from the original exchange and tagged message/ohttp-res. The relay shuttles bytes in both directions without ever holding a key that would let it read them.
Because the inner payload is binary HTTP rather than a fresh connection, OHTTP suits single request-and-response interactions. There is no long-lived session, no cookies surviving across requests, and no opportunity for the target to set a tracking identifier that persists.
Where OHTTP Is Not the Right Tool
OHTTP is sometimes confused with Tor or with a VPN. It is neither, and the differences are the point.
| Property | OHTTP | Tor |
|---|---|---|
| Hops | One relay, one gateway | Three relays, rotating circuits |
| Best for | Single request/response, telemetry, lookups | Interactive browsing, full sessions |
| Latency cost | Low, one extra hop | Higher, multiple hops |
| Trust model | Two named parties, assumed non-colluding | Distributed volunteers, no single trusted party |
Tor protects against a much broader adversary and provides stronger anonymity, at the cost of latency and a volunteer-operated network. OHTTP makes a smaller promise to a smaller threat model, and in exchange it is cheap enough to run on every metrics ping a large service sends. A VPN, by contrast, routes all your traffic through one operator who sees both your address and your destinations, which is exactly the pairing OHTTP refuses to allow.
OHTTP also does not hide that you are using OHTTP. The relay still sees your IP connecting to it. And it does nothing about timing or volume correlation if the same two operators decide to misbehave together. It is a targeted decoupling, not a cloak.
Where It Is Being Used
The protocol moved from draft to RFC because real systems needed it. It underpins privacy-preserving telemetry designs and aggregation protocols where a server should be able to count events without learning who generated them. Infrastructure providers including Cloudflare and Fastly have offered relay services, and the model fits any case where a service wants useful aggregate data without building a per-user dossier as a side effect.
The pattern generalizes well beyond HTTP requests. The same shape appears in Oblivious DoH, where DNS queries are split across a proxy and a resolver so that no one server sees both the client and the domain it is looking up. OHTTP is the more general statement of that idea.
The honest framing is that OHTTP narrows trust rather than removing it. You still trust that two organizations will not pool their logs. You have simply made the privacy-violating action require active collusion instead of passive default.
Why This Design Matters
Most surveillance is not the product of a single dramatic interception. It is the slow accumulation of metadata that nobody individually decided to weaponize. Request contents get paired with source addresses because that is what a normal server log looks like, and the profile assembles itself.
OHTTP is interesting because it changes the default. It takes a piece of infrastructure that would otherwise collect a linkable record and restructures it so the linkable record never exists in one place. That is a more durable kind of protection than a policy promise not to look, because it removes the capability rather than asking for restraint. If you care about metadata surveillance, designs that make the harmful correlation structurally impossible are the ones worth paying attention to.
It will not anonymize your browsing or replace Tor. But for the steady background hum of lookups and telemetry that modern apps generate, separating the who from the what is a meaningful improvement, and it is now a standardized, deployable one.
Originally published at havenmessenger.com
