Cloudflare OHTTP gateway

Of course it's not a CIA operation — that agency is foreign intelligence agency. The domestic intelligence agency is called NSA.

The more people join in and become dependent on CF, the more incentive there is to subvert CF. Or am I being dumb?

Another thing is the motivation to send people to work for CF. And another thing is the question of preparation vs hope.

Are you, by chance, an operative, sir? :)

The US Gov can just ask, and American corporations will deliver. No need to get their hands dirty.

You want to say the intelligence agencies are the biggest protectors of piracy (Piracy websites love Cloudflare)?

Is the DHS story not widely known?

    Five years later Mr Prince was doing a Master of Business Administration (MBA) at Harvard Business School, and the project was far from his mind, when he got an unexpected phone call from the US Department of Homeland Security asking him about the information he had gathered on attacks.
    
    Mr Prince recalls: "They said 'do you have any idea how valuable the data you have is? Is there any way you would sell us that data?'.

Source: https://www.bbc.co.uk/news/business-37348016

I may be naive, but they offer a privacy service which adds a hop on the way. They don't control both their server and the third-party, and that is the whole point of the design, right?

How is that exactly what you would expert from a covert government operation?

Do we agree that the design goes through two hops, only one of which is controlled by Cloudflare? And that it is the whole point of the design?

Why not both? When browsing Microsoft, give your IP to Cloudflare. When browsing Pouet, give your IP to Pouet.

What if the solution is garbage? There are ad blockers that click every ad. Random google searches, random chatbot searches, random clicks.

I have a feeling that privacy is easier to protect if you just mix what you want to hide with a lot of garbage.

There are other CNDs, and Cloudflare isn't event the largest one, it has best marketing and free solutions.

This separates who sees what. Cloudflare (or any OHTTP gateway) sees who talks to who, but can't see the content. The service sees the content but not who you are/your IP.

You can imagine a lot of threat models where who you talk to isn't sensitive, nor is "someone talked to them about X" but knowing both facts is a risk.

Many of those websites are hosted by big tech companies via their cloud offerings. These clouds have even developed software for reading files within the VMs they are hosting.

Nothing really prevents you from doing double encryption in OHTTP. The gateway decrypts once, and the origin (target resource) decrypts a second time. HPKE is a good choice to use for the inner layer.

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).

A clear example of when this might be a good idea is DNS-over-HTTPS — you don't want the resolver being able to correlate multiple requests from the same client.

You _can_ try and do this with SOCKS5, however you need to be very careful to avoid sharing any state:

* You must use a new TCP connection for each request, with a new TLS and HTTP connection atop.

* You must ensure you do not use TLS Session Resumption or 0-RTT data.

* You must, to the maximum extent possible, be very conservative with what you send in the TLS ClientHello to avoid exposing fingerprinting data.

SOCKS5 is also unencrypted, and the request contains the destination: the hostname if the proxy resolves it, or the IP if the client resolved it itself (and ECH doesn't help here, since it only protects the SNI inside the TLS handshake that follows). With OHTTP, that's all inside the TLS connection to the relay.

OHTTP doesn't have the client sending up-front metadata about all the different encryption methods it supports to the gateway (it relies on the gateway to tell it what it supports, and the client just picks one); the gateway doesn't get to see any of the TLS fingerprinting surface (because that is only visible to the relay).

OHTTP also doesn't require there to be multiple new TCP connections made for every request (whereas with SOCKS5 you're looking at a new TCP connection from the client to the proxy, and from the proxy to the server, per request) — you can have a long-lived connection to the relay, and the relay can have a long-lived connection to the gateway (shared by many clients). That's a big latency win for applications like DNS-over-HTTPS.

The risks of key disclosure also differ between the two — 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 (because there is forward secrecy); with SOCKS5, you have forward secrecy via the end-to-end TLS connection.

For the use-case of a general-use proxy, work such as MASQUE provides a multi-hop approach to limit exposure to any single party, and that does provide an end-to-end TLS connection — but you with that you're back to exposing all the fingerprinting associated with it, though for a general use proxy you may also be sending session-specific data (like auth tokens) that clearly tie requests together anyway.

But the whole point of this gateway is that Cloudflare doesn't learn "who makes the request" and "what they request", only one of them, right?

I guess the point is that a site owner can opt-out from the possibility to locate end-users. I think the use case is fair but not that common.

“Well you see, it’s better because of the fact the _we_ do it!” - Cloudflare, probably.

You already can't do that since the abuser will just buy residential proxies.

It adds some level of privacy without going as far as something like Tor. As a result, it's a lot faster than Tor, but a lot less private.

The "privacy" it adds is that it separates your IP from your request, so no one actor on the way knows "X requested Y". A server knows "X requested something", another one knows "someone requested Y".

Maybe you don't need it, but I don't see how this is slightly creepy.

yeah i’m genuinely interested if there is an actually service that uses this today

To those missing it, it’s a reference to an internal NSA presentation that shown this sentence with an arrow at the boundary of google network and the internet.

You can google the sentence directly to find it.

Reading between the lines: privacy regulaton?

Every data point you keep can be leaked, or abused, and has to be protected (at least in jurisdictions that don't just go eeh, whatever when it comes to protecting their citizens). There are tons of scenarios where I don't want your IP address, ideally I'd not even like to store your password. The more you store, the more you paint crosshairs on your back for hackers. You need to adhere to regulations, anonymise or delete it as customers leave, and solve problems like "should backups be immutable, or pruned from data I should no longer retain". At a certain size, you even need to defend on the inside to avoid more ruthless managers from abusing data you have been entrusted with for illegal analysis or data sales to analytics companies.

If your view on data protection or privacy is "I don't care about it, my users can go to hell as long as they pay"--then sure, this whole discussion probably seems pointless to you. But otherwise, storing and handling as little data as you can probably resonates with you as a good solution to many problems.

Agreed, but hopefully this gives people who would pay for it a way to do it and then, either by scale or by popularity, it becomes de facto.

I think an issue is that with such design, you want to "hide in the crowd". If you add a hop for your friends, then the third-party service knows that whoever connects from your server is one of your friends and it somehow defeats the purpose of the system, right?

OHTTP is like a two-hop Tor circuit with a predetermined gateway, so if they can pin you as the first hop it's similar

"Jesters do oft prove prophets".

- King Lear

They're already sort of inventing this by making the choice for everyone to block non-registered bots by default. (calling them "AI Training bots")

Like, bots are a huuuge problem but I am a huge believer in the case-by-case basis, and identity verification isn't a good default!

Not sure how north korean hackers benefit from not knowing who is accessing their servers?

I think you misunderstand. This is for inbound traffic, not outbound.

We have Cloudflare Tunnels to thank for this. I wish Cloudflare did more to stop malicious use of Cloudflare Tunnels.

I thought ohttp is opt-in. You have to participate their beta to enable the relay/gateway.

Same applies to Apple's Private Cloud Compute. A service provider has to join the program to avoid reading visitor's source IP.

It will handicap service provider's capability if I am not mistaken.

iCloud Private Relay (available on every macOS and iOS device in recent years) uses OHTTP to obscure your identity from sites you visit.

It's literally not MITM because they can't see the ciphertext, and specifically went out of their way to prevent themselves from being able to decrypt it (ie. you can't set up an OHTTP service where both hops are cloudflare).

It’s entirely possible if the application developers have made the choice to intentionally avoid tracking and tying personal data to user identity, which is exactly who this product is aimed at.