Oblivious HTTP gives a CLI or coding agent a way to send stateless requests whose content and sender identity are split across two parties: a relay that sees your IP but cannot read the request, and a gateway that reads the request but never learns your IP. For one-shot API calls and telemetry, that is lighter than Tor and more partitioned than a VPN, at the cost of per-request overhead and operational duties a managed tunnel never imposed.
What is Oblivious HTTP, and what is it not?
Oblivious HTTP is an IETF Standards Track protocol, published as RFC 9458 in January 2024, that encrypts individual HTTP requests so no single infrastructure party can link who sent a request to what it contains. The authors are Martin Thomson of Mozilla and Christopher A. Wood of Cloudflare, which tells you something about the pedigree: this is not a vendor side project, it is a protocol two competing organizations agreed to standardize.
The mechanism is a two-party split built on Hybrid Public Key Encryption. The client obtains the gateway’s public key configuration, encapsulates its request with HPKE, and sends the ciphertext to a relay. The relay sees the client’s IP address but holds no key, so it forwards opaque bytes. The gateway holds the private key and can decrypt the request, but the transport connection comes from the relay, so it never learns the client IP. Per the protocol’s documentation on http.dev, neither party alone can reconstruct the link between identity and content.
What it is not matters as much. OHTTP is an application-layer proxy that forwards individual application messages, not network-layer connections. Cloudflare’s own analysis is explicit that general-purpose HTTP and web browsing are out of scope. The IETF working group charter confined the design to discrete transactional queries: DNS resolution, telemetry submission, certificate revocation checking. If your workload is a session with cookies, auth state, or connection reuse, OHTTP was deliberately not built for it.
The working group has since been marked “Replaced” on the IETF datatracker, which is IETF for finished rather than abandoned. RFC 9458 remains the Standards Track output and the reference every implementation works against.
How does OHTTP’s trust model compare to a VPN and Tor?
A VPN concentrates all trust in one entity, Tor spreads it across at least three hops, and OHTTP splits it across exactly two parties that must not collude. That is the whole comparison, and each option’s failure mode follows directly from its structure.
A conventional VPN, or a connection-oriented tunnel like WireGuard or Cloudflare WARP, terminates your traffic at a single provider. That one entity can see identifying information about the user and all of the activity passing through it. You are not reducing trust, you are relocating it. For a corporate egress policy that is often fine, because the employer is the trusted party by construction. For hiding telemetry or API traffic from the infrastructure operator itself, it is useless.
Tor decouples sender from receiver through three or more intermediate hops, which gives genuinely stronger anonymity but at the cost of latency, bandwidth constraints, and an operational profile that makes it a poor fit for a build script or an agent harness that needs to reach one specific API. RFC 9458 itself positions OHTTP as the cheaper point on the spectrum: “simpler and less costly than more robust systems, like Prio or Tor, which can provide stronger guarantees at higher operational costs.” The RFC says the quiet part directly. You are trading away Tor-grade anonymity for something cheap enough to put on every outbound request.
OHTTP’s middle position rests on one assumption: the relay and the gateway are run by separate, non-colluding entities. If the same organization controls both, or the two operators share logs, the separation collapses and client identity becomes linkable to request content again. Critically, this is an assumption the client cannot cryptographically audit. Cloudflare published a formal, computer-aided security analysis in October 2022 that verifies the unlinkability properties hold given non-collusion. The proof covers the protocol, not the business arrangement. Whether Cloudflare’s relay and a given gateway actually keep their logs separate is a procurement question, not a mathematical one.
How is OHTTP different from iCloud Private Relay?
Apple’s iCloud Private Relay and OHTTP both use a two-hop structure with split trust, but they operate at different layers: Private Relay proxies entire connections for always-on browsing, while OHTTP proxies individual requests for one-shot operations. They are complementary, not competitors.
Private Relay tunnels all Safari traffic through a connection-level proxy, which makes it behave like a VPN with the trust split in half: Apple sees who you are but not where you are going, and the egress partner sees where you are going but not who you are. That design suits persistent, stateful browsing. It does not suit a single HTTPS POST from a CI job, because standing up a connection-oriented tunnel for one message wastes everything the tunnel was built to amortize.
The cost asymmetry is documented. Cloudflare’s protocol analysis notes that connection-oriented proxies (HTTP CONNECT, VPNs, WireGuard, WARP) are general-purpose because they proxy entire TCP connections, and that achieving OHTTP-style per-message unlinkability with them would require a fresh end-to-end TLS connection per message, which Cloudflare describes as prohibitively expensive for all participants. OHTTP exists precisely because encrypting one message with HPKE is cheap, while negotiating a tunnel per message is not. For a CLI or agent making discrete calls, request-level is the right granularity and connection-level is overhead you do not need.
Where does a privacy proxy CLI fit a developer’s workflow?
The fit is stateless, transactional egress: the one-shot API call, the telemetry beacon, the revocation check, anywhere a tool phones home and you would rather the receiving service not learn the caller’s network identity. That description covers a large fraction of what modern CLIs and coding agents actually send.
The production precedent is already established, and it is not hobbyist. As of 2024 and 2025, per Wikipedia’s deployment summary, Apple routes OHTTP through relay services for Private Cloud Compute, Meta uses a relay for Meta private processing, and Mozilla uses one with Fastly for Firefox telemetry. The pattern across all three is identical: a client device or agent needs to submit something sensitive to a vendor service, and the vendor wants to honestly claim it cannot see who submitted it. Notice that two of the three are AI-flavored workloads. The request pattern of a coding agent, short stateless calls to a model API plus telemetry, is exactly the shape OHTTP was chartered for.
Discovery and key distribution are standardized enough to wire into a client without bespoke infrastructure. The http.dev reference documents that gateways advertise via SVCB DNS records and expose their key configuration at a well-known URI, with keys rotated periodically. A CLI that wants OHTTP egress needs a relay URL, a key config fetch, and an HPKE encapsulation library. That is an application-layer config change, not an infrastructure procurement.
That last point is the consequence worth sitting with. Privacy-preserving egress has historically been a network team’s decision: buy a VPN, run Tor relays, negotiate with Apple. Request-level OHTTP moves it into the application, which means the decision now lands on whoever maintains the agent harness or the CLI. Most agent harnesses today phone home over plain TLS with the client’s IP fully visible to the model provider and the telemetry endpoint. An open-source proxy CLI lowers the cost of closing that gap to roughly the cost of adding a dependency. The teams that wrote those harnesses mostly did not treat egress metadata as a threat surface. They are about to lose the excuse that fixing it was expensive.
What operational burden do you inherit?
The team wiring OHTTP into a tool takes on key rotation discipline, rate limiting, network-delay tolerance, and relay trust selection, none of which a managed VPN or Tor ever asked of an application developer. The protocol hides metadata; it does not manage itself.
The sharpest caveat is forward secrecy, or rather its absence. Per http.dev’s protocol notes, OHTTP provides no forward secrecy during a key configuration’s lifetime. If the gateway’s long-term private key is compromised, an attacker holding recorded ciphertext recovers the plaintext of every request made under that key. The only mitigation is rotating gateway keys frequently enough to shrink the exposure window, and rotation is the gateway operator’s job, which means it becomes your vendor-management job.
The performance cost is real and structural, not an implementation bug. RFC 9458 states that every OHTTP request requires at least two regular HTTP requests, adding latency; the message expands with HTTP fields, encryption metadata, and AEAD expansion overhead; and each request carries non-negligible cryptographic computation. For a telemetry beacon none of this matters. For an agent making latency-sensitive model calls in an interactive loop, the double hop and per-request crypto belong in the budget, not in the footnotes.
Then there is relay selection, the burden with no tooling behind it. Because the privacy guarantee is a non-collusion assumption the client cannot audit, choosing a relay is a judgment call about organizational separation and logging practice. Pointing your agent at a relay and gateway that quietly share an operator gives you the overhead of OHTTP with the privacy of a direct connection.
Which egress option should your CLI actually use?
For one-shot, stateless API or telemetry calls where you want the receiving service unable to identify the sender, use OHTTP; for general-purpose tunnels, stateful sessions, or browsing, use a VPN, WARP, or Private Relay; reserve Tor for when you need real anonymity and can absorb its cost. The decision axes line up cleanly:
| Axis | OHTTP | VPN / WARP / WireGuard | Tor | iCloud Private Relay |
|---|---|---|---|---|
| Trust model | Two non-colluding parties | One trusted entity | Three or more hops | Two parties, Apple + egress partner |
| Coverage scope | Single stateless requests | Entire TCP connections, general-purpose | General-purpose, high latency | All browser traffic, persistent tunnel |
| Per-use overhead | Two HTTP hops, HPKE crypto, AEAD expansion | Tunnel setup amortized over connection | High latency and bandwidth cost | Tunnel setup amortized over session |
| Forward secrecy | None within a key config lifetime | Per connection | Per circuit | Per connection |
| Operational burden | Key rotation, rate limits, relay trust vetting | Provider selection, then near zero | Relay operation or exit risk | None for the end user |
| Workload fit | CLI/agent API calls, telemetry, revocation checks | Corporate egress, arbitrary traffic | Strong anonymity requirements | Consumer browsing |
Two caveats ride on any row of that table. First, OHTTP’s two-party privacy is an assumption, not an auditable property: collusion between relay and gateway voids it silently. Second, OHTTP is explicitly out of scope for general-purpose browsing and stateful sessions, per both the RFC and Cloudflare’s documentation. It is not a drop-in replacement for a VPN or Tor, and any tooling that presents it as one is overselling.
The practical verdict, then: for the transactional, stateless traffic that dominates what CLIs and coding agents emit, OHTTP is the lightest credible way to stop leaking caller identity to the services those tools call, and an open-source client CLI would make adopting it a config decision instead of a procurement one. The price is that key rotation, rate limiting, delay tolerance, and relay vetting move onto your team’s plate, and the forward-secrecy gap means recorded traffic stays decryptable for the life of each gateway key. The protocol underneath it is two years of Standards Track RFC and three hyperscaler deployments deep. Wire it in where the traffic is stateless, rotate the keys like you mean it, and keep the VPN for everything else.
Frequently Asked Questions
Does OHTTP support forward secrecy for recorded traffic?
No. OHTTP provides no forward secrecy during a key configuration lifetime. If the gateway’s long-term private key is compromised, an attacker with recorded ciphertext recovers plaintext for all requests under that key. Teams must rotate keys frequently to limit the exposure window, and a 2025 NCC Group assessment noted that deployment requires careful management of key rotation and rate limiting.
How does OHTTP compare to connection-oriented proxies like WARP?
Connection-oriented proxies like WARP proxy entire TCP connections and are general-purpose. Achieving OHTTP-style per-message unlinkability with them would require a fresh end-to-end TLS connection per message, which Cloudflare describes as prohibitively expensive for all participants. OHTTP exists because encrypting one message with HPKE is cheap, while negotiating a tunnel per message is not.
What are the operational costs of adopting OHTTP for a CLI?
Teams wiring OHTTP inherit key rotation discipline, rate limiting, network-delay tolerance, and relay trust selection. The protocol hides metadata but does not manage itself. Choosing a relay is a judgment call about organizational separation and logging practice, as the privacy guarantee is a non-collusion assumption the client cannot cryptographically audit.
Can OHTTP replace a VPN for general-purpose browsing?
No. OHTTP is explicitly out of scope for general-purpose browsing and stateful sessions. It is designed for discrete transactional queries like DNS resolution, telemetry submission, and certificate revocation checking. If your workload involves cookies, auth state, or connection reuse, OHTTP was deliberately not built for it.
