I have absolutely no reason to think Cloudflare is a covert CIA operation. In fact, I’m sure there are plenty of good reasons to think it isn’t. But if it were, pretty much everything it does is exactly what you'd expect from one.
NSA's mission, as outlined in Executive Order 12333 in 1981, is to collect information that constitutes "foreign intelligence or counterintelligence" while not "acquiring information concerning the domestic activities of United States persons".
Ok, so grant for the moment that it’s both the largest conspiracy ever and the best kept secret ever.
How is anyone worse off using their OHTTP gateway than not using it? Is the idea that CF is this spectacular conspiracy, but nobody thought of capturing traffic from backbones?
As cloudflare is the gateway for half the Internet and the other half is meta Google and Microsoft, I would prefer to share my IP with the website I visit instead some big tech companies.
> Meanwhile, some app developers end up knowing more about their users than they’d care to: a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Can someone expand on “burden” here? Scenarios that come to mind for me are something like: “I now need to ensure my log files are stored securely but that’s a PITA.” This doesn’t feel like the best example of why I’d use this though. (Edit: Secure messaging servers for a service like Signal?)
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.
"I don't care about it, my users can go to hell as long as they pay"
The above is also a good reason why you wouldn't want to get any of their data.
Users who are not consumers are of no interest, and users who become customers will give the necessary data to make a purchase without any need to spy on them.
So.. they continue having access to private identifiers, while you willingly give it up to "protect privacy"? Piping all of that data into a massive central database instead of your nginx logs? How is this supposed to be better?
> such that only the client and app server can see plaintext, and the relay sees only a jumble of ciphertext. A “gateway” sits between the relay and app server to handle all of this cryptography — decapsulating requests, encapsulating responses — and the app server handles only plain HTTP
Wouldn't that be better if you design an oblivious encryption method so the encryption and decryption is handled by the origin server (a.k.a Target Resource in the RFC) and the Client? Instead of letting anyone in the middle to handle that data?
Their current design looked not that different than if you just connect to a public anonymous SOCKS5 server (which don't decrypt TLS traffic) and uses it to connect to a website hosted behind Cloudflare. It would probably work the same way too, since someone has to host a "OHTTP Relay" the same way they host a anonymous SOCKS5 server.
Hm. Interesting. I wonder how you would add "banning abusers by IP" functionality to it though — you first need to identify the abuse somehow and then link it to the originating IP (or any other kind of identifier)...
Cloudflare Warp has been more of an issue for a small webapp I run than residential proxies. Because it's a mix of legitimate users whom I guess installed the 1.1.1.1 app and have no idea they're tunnelling all their traffic through Cloudflare, and abusive users. I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.
At my previous job we routinely gave out IP-based bans, and it worked pretty well; the most insistent guys gave up after their third or fourth IP banned at most.
If I want to preserve the privacy of my users I will avoid using massive behavior capturing networks like Cloudflare. The is no world where giving them the tracking is better then just ensuring I anonymize my logs. If my users don't trust me; and are informed enough to understand what this service dose and doesn't cover they are just going to assume I can fingerprint them in some other way.
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.
> a typical client-server exchange creates a trail of user data, like the client’s IP address or TLS fingerprint. This level of visibility can be a burden.
Does Cloudflare's WAF (which relies on TLS Fingerprinting) stop working if OHTTP is enabled? If not, does this imply the client metadata is read and processed by Cloudflare but not passed on to the application server?
The irony is that the majority of people that need this don’t have the cognitive time or skill to process and set it up for themselves. But the agents and bad actors like North Korean hackers would absolutely have the time and ability to implement and use it. Then you have the market for lemons problem - if requests coming from here are malicious most requests coming from here will be seen as malicious. Aka dark alleys earn their reputation over time.
Pathetically, people probably won't even erase cookie, let alone JavaScript. To begin with, any websites are not designed to be viewable without js. There are countless ways to find fingerprints. It is impossible to prevent tracking anyway in current the internet.
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.
Comments (44)
Whether they abide by that is another matter.
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? :)
How is anyone worse off using their OHTTP gateway than not using it? Is the idea that CF is this spectacular conspiracy, but nobody thought of capturing traffic from backbones?
But maybe I get privacy wrong.
Can someone expand on “burden” here? Scenarios that come to mind for me are something like: “I now need to ensure my log files are stored securely but that’s a PITA.” This doesn’t feel like the best example of why I’d use this though. (Edit: Secure messaging servers for a service like Signal?)
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.
The above is also a good reason why you wouldn't want to get any of their data. Users who are not consumers are of no interest, and users who become customers will give the necessary data to make a purchase without any need to spy on them.
Wouldn't that be better if you design an oblivious encryption method so the encryption and decryption is handled by the origin server (a.k.a Target Resource in the RFC) and the Client? Instead of letting anyone in the middle to handle that data?
Their current design looked not that different than if you just connect to a public anonymous SOCKS5 server (which don't decrypt TLS traffic) and uses it to connect to a website hosted behind Cloudflare. It would probably work the same way too, since someone has to host a "OHTTP Relay" the same way they host a anonymous SOCKS5 server.
But that aside - surely this won't help for websites with Google tracking code embedded, which are the sorts of sites that track you anyway?
CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.
You can google the sentence directly to find it.
Does Cloudflare's WAF (which relies on TLS Fingerprinting) stop working if OHTTP is enabled? If not, does this imply the client metadata is read and processed by Cloudflare but not passed on to the application server?
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!
- King Lear
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.
What about browsers making general website requests to services that support it?