BuildNot yet confirmed elsewhere1 publisher2 min readPublished Updated
Cloudflare's OHTTP Gateway declines to decrypt anything that reaches it through Cloudflare
Cloudflare's OHTTP Gateway beta will not decrypt requests that arrive from Workers or from hosts proxied through Cloudflare. Anyone adopting it needs a relay hosted by a different operator.
The Engineer · Build desk
Map of five parties. The relay sees the client's IP but cannot read the request. The gateway decrypts it and sees only the relay's address. Cloudflare's Gateway will not decrypt Worker or Cloudflare-proxied traffic. Relay and app server must be separate parties. Cloudflare supplies no relay.
- exposure Relay operator Sees the client's IP address but cannot read the request, claim 4
- exposure Gateway operator Decrypts the request and sees its contents, but only ever sees the relay's address, claim 4
- decision Cloudflare OHTTP Gateway Will not decrypt requests reaching it from Cloudflare Workers or hosts proxied through Cloudflare, claim 2
- constraint Relay and app server operators The model requires separate, non-colluding parties, per authors Lara Schull and Akshat Mahajan, claim 5
- constraint Adopters Cloudflare does not supply a relay; it says relays can run on any infrastructure provider, claim 6
| Who | How | Kind | Claim |
|---|---|---|---|
| Relay operator | Sees the client's IP address but cannot read the request | exposure | 4 |
| Gateway operator | Decrypts the request and sees its contents, but only ever sees the relay's address | exposure | 4 |
| Cloudflare OHTTP Gateway | Will not decrypt requests reaching it from Cloudflare Workers or hosts proxied through Cloudflare | decision | 2 |
| Relay and app server operators | The model requires separate, non-colluding parties, per authors Lara Schull and Akshat Mahajan | constraint | 5 |
| Adopters | Cloudflare does not supply a relay; it says relays can run on any infrastructure provider | constraint | 6 |
What happened
- The Gateway binds to a customer zone and listens at a fixed path, https://your-zone.com/.well-known/ohttp-gateway, so a customer cannot point it at another domain.
- Cloudflare Access runs before decryption, so the relay can be authenticated with mutual TLS, static service credentials, or custom external logic.
- Standard and chunked OHTTP both work, and Cloudflare recommends chunked for performance.
- Cloudflare is renaming its existing Privacy Gateway product to Cloudflare OHTTP Relay to separate the two sides.
Why it matters
- cost The cost sits in the relay operator's logs. Cloudflare's authors say the hard part is being able to "verifiably promise to your users that you won't inspect logs with client identifiers."
- exposure An app that puts a session token or an email address inside the sealed request hands the gateway operator the identity OHTTP was meant to withhold, and the refusal does nothing about that.
- constraint The fit is narrow. In gsnedders' words, OHTTP suits "stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client."
The client encrypts the inner request to the gateway's public key with HPKE, as RFC 9458 specifies, and sends the sealed payload to a relay [3]. The relay sees the client's IP address and cannot read the request. The gateway reads it and sees only the relay's address [4]. A Worker in front of the Gateway, or a relay proxied through Cloudflare, would leave one company holding both the hop that knows who the client is and the hop that decrypts the request [15]. The post's authors, Lara Schull and Akshat Mahajan, write that the model "requires that the relay and app server be operated by separate, non-colluding parties." [5]
In our view the refusal is the right default. It is unusual for a vendor to ship a guard against itself, but a managed gateway that sat quietly behind Cloudflare's own relay would look correct on the wire and hide nothing.
The guard covers one route. InfoQ's account does not say how the Gateway recognises Workers or proxied traffic, or whether it checks anything beyond that. Cloudflare does not supply a relay and says relays "can run on any infrastructure provider, and they're simple." [6] The other routes to failure are the relay operator's logs [7] and the request body. Cloudflare's post says OHTTP "provides privacy at the network level, and doesn't touch the inner request body." [13]
Hacker News commenter gsnedders compared OHTTP with a SOCKS5 proxy. Matching OHTTP's unlinkability with SOCKS5 means a new TCP connection for every request and no TLS session resumption or 0-RTT [17]. With OHTTP, the client can keep a long-lived connection open to the relay, and the relay can keep one open to the gateway. For workloads like DNS over HTTPS, he said, that saves a significant amount of latency [20]. He listed the cost too, writing that "disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy)" [19]. Cloudflare manages the HPKE keys on this product [10], so the key whose leak matters most is one Cloudflare manages.
gsnedders added that OHTTP keeps the TLS fingerprinting surface away from the gateway [18]. That bears on a question commenter arshxyz raised: whether Cloudflare's WAF, which relies on TLS fingerprinting, keeps working. According to InfoQ, the announcement does not address that interaction [21].
What to watch
- Which infrastructure providers publish relays aimed at Gateway customers, since Cloudflare supplies none for it.
- How Cloudflare documents rotation of the managed HPKE keys, given the no-forward-secrecy point raised on Hacker News.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption
- Insufficient
- Hype gap
- Insufficient
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Cloudflare has opened a closed beta of the Cloudflare OHTTP Gateway, a managed endpoint that decrypts Oblivious HTTP requests on an origin's behalf.
- [2]
The Gateway will not decrypt requests that reach it from Cloudflare Workers or from hosts proxied through Cloudflare.
- [3]
Oblivious HTTP, standardized as RFC 9458, has the client encrypt the inner HTTP request to the gateway's public key using HPKE and send the sealed payload to a relay.
- [4]
The relay sees the client's IP address but cannot read the request; the gateway decrypts it, forwards plain HTTP to the application, sees the contents, and only ever sees the relay's address.
- [5]
Authors Lara Schull and Akshat Mahajan write that the model "requires that the relay and app server be operated by separate, non-colluding parties."
ReportedSupportedSource: Lara Schull and Akshat Mahajan, Cloudflare post, as quoted by InfoQView cited source - [6]
Cloudflare does not supply a relay for the Gateway, and says relays "can run on any infrastructure provider, and they're simple."
- [7]
The hard part, per the post, is being in a position to "verifiably promise to your users that you won't inspect logs with client identifiers."
- [8]
Cloudflare is renaming its existing Privacy Gateway to Cloudflare OHTTP Relay to separate the two sides.
- [9]
The Gateway binds to a zone and listens at a fixed path, https://your-zone.com/.well-known/ohttp-gateway, which stops a customer from pointing their gateway at another domain.
- [10]
Cloudflare manages the HPKE keys and serves the public keys from the same fixed path in response to a GET; clients can fetch keys over a different IP address than the one they use for requests.
- [11]
Standard and chunked OHTTP both work, with chunked recommended for performance.
- [12]
Cloudflare Access runs before decryption, so the relay can be authenticated with mutual TLS, static service credentials, or custom external logic.
- [13]
The post says OHTTP "provides privacy at the network level, and doesn't touch the inner request body," and that "it's up to you not to send identifying information (e.g. a user's email address or username) in the request body."
- [14]
If a session token or an email address is put inside the sealed request, the gateway operator has the identity the protocol was meant to withhold.
- [15]
Putting a Worker in front of the Gateway, or proxying the relay through Cloudflare, would route the client-identifying hop and the decryption hop through the same company, so Cloudflare built a product that declines to run in that configuration.
- [16]
Hacker News commenter gsnedders wrote: "OHTTP is designed for a relatively narrow use case: stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client (i.e., it's not just about hiding the IP address)."
- [17]
Per gsnedders, matching OHTTP with a SOCKS5 proxy means a new TCP connection for every request, no TLS session resumption or 0-RTT, and a deliberately conservative ClientHello.
- [18]
gsnedders said OHTTP keeps the TLS fingerprinting surface away from the gateway.
- [19]
gsnedders wrote: "With OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less."
- [20]
gsnedders said OHTTP allows long-lived connections from client to relay and relay to gateway, which he called a significant latency win for workloads like DNS over HTTPS.
- [21]
Commenter arshxyz asked whether Cloudflare's WAF, which relies on TLS fingerprinting, stops working in this setup; InfoQ describes this as a product interaction the announcement does not address.
Sources
1 independent publisher whose own reporting we read for this story.
- infoq.comCloudflare’s OHTTP Gateway Refuses to Decrypt Requests That Arrive Through Cloudflare
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.