Build1 publisher2 min readPublished
Cloudflare's paid OHTTP Gateway needs a relay run by another company to hide users' IPs
Cloudflare will sell an Oblivious HTTP gateway as a paid zone add-on from this fall, with a closed beta open now. It handles the decrypting half of a protocol built for two operators, and Cloudflare pitches it on lower latency than a self-run gateway.
The Engineer · Build desk
What happened
- OHTTP sends each request through two independently run hops: a relay that blindly forwards it to hide client identifiers, and a gateway that decrypts it.
- Cloudflare says customers whose servers already sit behind its network cannot also use its own relay, so the new gateway is the product meant for them.
- The gateway will run on every server in Cloudflare's anycast edge network, which Cloudflare says minimizes latency between relay and gateway.
- OHTTP already runs in Flo Health's Anonymous Mode and in Apple's Private Cloud Compute, where it separates AI inference requests from user identities.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Where a team hosts today decides which half it must run itself: hosting off Cloudflare means operating its own gateway, hosting on Cloudflare means sourcing a relay from another company.
- exposure Because Cloudflare decrypts every request it gateways, adopters hand request contents to Cloudflare while the outside relay operator holds client addresses.
- capability Apps already on Cloudflare's CDN or Workers can accept OHTTP traffic from third parties such as Apple's LiveCallerID without building and operating a gateway of their own.
Cloudflare's gateway is the hop that decrypts. It unwraps each encrypted request and wraps the response, so the app server can handle the traffic as plain HTTP [5]. The post calls the split between relay and gateway critical because it ensures no single party sees both client identifiers and request contents [6]. If Cloudflare ran both hops for one app, the address and the contents would sit with one company.
Cloudflare says customers can start receiving OHTTP traffic with just a few clicks [2]. Those clicks set up the receiving end. Requests reach the relay already encrypted [4], so the client app has to do the encryption before the request leaves the device. The post does not name relay operators other than Cloudflare, give a price for the add-on, or publish latency figures.
The latency work is the best engineering in the announcement. Cloudflare wrote that "we've seen how difficult it can be to build and operate a secure, performant OHTTP gateway at scale" [15]. Any proxy adds an extra hop or two, and decrypting requests and encrypting responses adds more cost, so a homegrown setup can take a significant latency hit, according to the post [12]. The gateway is built from the same pieces Cloudflare uses for 1.1.1.1 and iCloud Private Relay [14]. Running it on every edge server shortens the relay-to-gateway leg [13]. The client-to-relay leg belongs to the relay operator. I'd expect the managed gateway's advantage to hold mainly where that relay also sits close to Cloudflare's edge.
In my view, for a team already serving from Workers, buying the gateway is the right trade. The gateway is the half Cloudflare says is hard to run well [15], and the relay has to come from another operator regardless [9]. A relay sold as Privacy Gateway was always going to confuse buyers once a real gateway shipped, so Cloudflare is renaming the 2022 product Cloudflare OHTTP Relay [7].
What to watch
- The per-zone price Cloudflare sets when the gateway moves from closed beta to the paid add-on this fall.
- Which third-party relay operators announce support for forwarding to Cloudflare-hosted gateways.
- Latency figures from beta customers comparing the managed gateway with self-run OHTTP gateways.