OBLIVIOUS HTTP
What Oblivious HTTP separates, and which metadata remains.
Encrypting an HTTP connection protects a request from observers on the path. It does not hide the client’s network address from the service receiving the request. The endpoint necessarily sees both who connected and what was requested.
Oblivious HTTP changes that topology. A client encrypts an HTTP message to a gateway and sends the encapsulated request through a relay. The relay sees the client’s connection but not the request content. The gateway sees the decrypted request but not the client’s direct network connection.
The privacy property comes from partitioning information across parties, not from making metadata disappear.
Relay and gateway have different views
The relay forwards an opaque message toward the gateway. It can observe the client IP address, connection timing, approximate message size and the selected gateway.
The gateway decapsulates the request, processes it or forwards it to the target, and encrypts the response. It sees request content and application semantics but receives the request through the relay rather than directly from the client.
Neither party should see the complete pair of network identity and plaintext request. If they collude or share detailed logs, the partition collapses.
HPKE protects an encapsulated HTTP message
The client serializes the request using Binary HTTP and encrypts it with Hybrid Public Key Encryption under a gateway configuration. HPKE establishes request and response contexts from one encapsulation.
Configuration identifies the KEM, KDF and AEAD suite along with a key identifier. Those bytes are protocol inputs. A client must reject unsupported combinations and avoid silently falling back to ordinary HTTP when oblivious transport is required.
The gateway’s private key becomes a decryption boundary for many clients and needs explicit rotation, overlap and compromise handling.
The response is bound to the request context
The gateway encrypts its response using keying material derived from the original HPKE context. The client does not treat the response as an unrelated encrypted object.
This binds the response to the request encapsulation and prevents another gateway response from being substituted trivially. Implementations must keep the context until the response completes and discard it safely after use.
Retries normally create new encapsulations. Reusing request context across attempts can create cryptographic and linkability problems.
Message size remains visible
Encryption conceals content but preserves approximate length. A relay can classify distinctive request sizes; a gateway can classify response sizes and timing. An observer able to see both sides may correlate them.
Padding can place messages into broader size classes, but padding policy is an application decision. Exact padding to one maximum wastes bandwidth. Fine-grained buckets may still fingerprint rare operations.
A useful profile specifies request and response padding together with the anonymity set it is intended to produce.
Timing is a shared signal
A request that enters a lightly used relay and immediately leaves one gateway may be easy to correlate even when sizes are padded. Connection reuse, batching and traffic volume affect this risk.
OHTTP is not a general-purpose anonymity network. It limits which application-layer information is available to each role under a defined trust model. It does not promise protection against a global passive observer.
The distinction should appear in deployment claims. Hiding an IP address from a target is not the same as hiding communication from the network.
The plaintext can identify the client
A gateway that cannot see the source address may receive a request containing an account token, device identifier or stable cookie. OHTTP does not remove identifiers inside the protected message.
For anonymous use, the application request must be designed accordingly. Privacy-preserving authorization tokens can help prove eligibility without introducing an account identifier, but headers, URLs and payloads still need review.
Transport partitioning and data minimization solve different parts of the same problem.
Replay needs application semantics
An encrypted request can be copied and forwarded again. HPKE authenticates the encapsulated content; it does not decide whether the operation is safe to repeat.
The target may need request identifiers, expiration, nonces or idempotency rules. A replay cache at the gateway can help but creates state and synchronization requirements.
Responses lost between relay and client make retries ambiguous. The application should know whether a repeated request creates another action or retrieves the result of the first.
Errors can become an oracle
Malformed encapsulations, unknown key identifiers, expired configurations and target failures occur at different layers. If their responses differ in timing or size, the relay or client may learn more than the protocol intends.
A gateway should validate lengths and cryptographic inputs before processing Binary HTTP. Error responses need a controlled representation, and diagnostic detail should remain in internal logs rather than observable ciphertext classes.
Discovery is part of the trust path
Clients need the gateway URI and public-key configuration. DNS service parameters and well-known resources can advertise them, but discovery must be authenticated and freshness-controlled.
A stale key can cause failures. A maliciously substituted gateway configuration can redirect plaintext after decapsulation. TLS protects retrieval, while the application still decides which target is authorized to name which gateway.
Operational separation must be real
The protocol assumes limited trust in the relay and gateway. That assumption should be reflected in ownership, access controls, logging and incident response.
If both services export raw event streams into one analytics system keyed by timestamp, they may recreate the linkage the protocol removed. Privacy boundaries apply to observability infrastructure as well as request processing.
Partitioning instead of invisibility
Oblivious HTTP does not make a request invisible. It gives different parties deliberately incomplete views.
The relay knows where the connection came from. The gateway knows what the encrypted request contained. Padding, timing, identifiers and collusion define how well those views remain separate.
No intermediary should see the whole request because no intermediary needs the whole request to perform its role.
