ohttp: Oblivious HTTP protocol in Go

Oblivious HTTP (OHTTP), or “Enterprise TOR” as I like to call it, is a specification for making anonymous requests to servers on the Internet. The spec (RFC 9458) was developed in Oct ‘21 and published on Jan ‘24. The “chunked” (e.g., for streaming) version began development in Aug 2023 and is not yet finalized. And it’s used more broadly than you might realize:

• Apple for iCloud Private Relay, Enhanced Visual Search, and Private Cloud Compute
• Divvi Up
• Flo
• Google for the FLEDGE project and Safe Browsing API
• Meta for WhatsApp’s Private Processing 
• Mozilla for Firefox
• Payjoin

To name a few

The critical insight is as follows: if you want to be anonymous to an entity, you can’t trust that entity to anonymize you. You need another entity to anonymize you, but nothing more.

So, similar to Tor, OHTTP uses an intermediary to obfuscate the true source of a request. Specifically, this intermediary, called a “relay”, forwards a source’s HTTP request to a target recipient after stripping identifying metadata from the request. Importantly, the HTTP request body is encrypted before being sent to the relay. The relay can see the source but cannot see the content; meanwhile, the recipient cannot see the source but can see the content. It’s like sending a letter without a return address, where the postal service cannot possibly open the letter.

If you’re reading closely, you might note that this system still relies on trust – the only way this works is if the relay and target do not collude. Otherwise, the relay could simply forward identifying information, or the target could share its decryption key with the relay. In practice, the way this risk is mitigated is by asking a disinterested third-party to run relays and be sure that third party has a financial incentive not to collude with the target. There are 3 main providers for OHTTP relays: Cloudflare, Fastly, and oblivious.network – their reputation and their revenue hinge on not colluding.

On CONFSEC and following Apple’s lead, we believe anonymization is central to private inference. By anonymizing all inference requests, we raise the bar for any threat actor attempting to compromise privacy. In particular, if all requests are anonymous, it forces a threat actor to compromise all requests in the system and then sift through anonymous data in the hopes of targeting an individual user. It also means that we as an operator cannot single out a user or choose to record their data. We don’t know who is making any particular request!

CONFSEC uses OHTTP as part of our anonymization approach, BUT there was not a Golang implementation that was production-ready, tested, supported streaming/chunking, provided client and server implementations, handled key rotation, and provided a Go-native abstraction via HTTP middleware. So, we wrote one. Please check out the docs for examples and comparisons. And, if you need to run OHTTP for your product, I’m happy to help intro you to the right folks at any of those 3 providers.

transport, err := ohttp.NewTransport(keyConfig, relayURL)
if err != nil {
	log.Fatalf("failed to create ohttp transport: %v", err)
}

client := &http.Client{
	Transport: transport,
	Timeout:   60 * time.Second,
}

Setting up an OHTTP client in go is easy, just swap in a new transport and treat it like a normal HTTP client

I also wanted to call out one of our OHTTP providers: Fastly. Fastly is handling tens of millions of requests for us through their OHTTP relay with 10-20ms latency. We could not be happier with their production support, pricing, and ease of use. They’ve been great partners and have been critical in establishing an important guarantee to our customers.

We also work with oblivious.network as our failover provider and they’re incredibly easy to set up – fully self-serve – and offer the same perf. I recommend both!