Rendered at 03:09:14 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
simondotau 18 hours ago [-]
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.
1a527dd5 11 hours ago [-]
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?'.
first thing i thought of. cloudflare is like the most successful widely scaled man in the middle attacker who may or may not be attacking of all time
Joker_vD 18 hours ago [-]
Of course it's not a CIA operation — that agency is foreign intelligence agency. The domestic intelligence agency is called NSA.
groomlake 14 hours ago [-]
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".
Well, you see, Your Honor, when the foreign entities do the spying inside the US, they inevitably become one side in the domestic activities of United States persons. So it's only reasonable to conclude that this part of the Executive Order is null and void.
arcanemachiner 9 hours ago [-]
Well, their operations are (intended to be) foreign... But that hasn't stopped them from selling drugs to American to raise money for their operations.
Also the NSA is a "signals intelligence" agency... Wouldn't the FBI be the local analog to the CIA? Or maybe the DHS?
bladeacidic 9 hours ago [-]
Well, the problem with that is then you have to deal with the legalities of the USA. What you do instead is have the UK (and a couple other eyes, up to five or eighteen) do the spying on Americans, and in exchange, the Americans will spy on the UK. All perfectly extra-legal.
9dev 14 hours ago [-]
Two branches from the same trunk with their leaves touching. The boundaries are pure show.
gigatexal 13 hours ago [-]
Other than platforming some of the worst people on the web … a lot of the stuff coming out of Cloudflare has been really awesome. No egress fees R2 is top of mind.
phatfish 14 hours ago [-]
The US Gov can just ask, and American corporations will deliver. No need to get their hands dirty.
palata 11 hours ago [-]
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?
gruez 10 hours ago [-]
>They don't control both their server and the third-party, and that is the whole point of the design, right?
Yeah I'm not sure what everyone's complaining about. The lack of criticism of anything specific about OHTTP makes me think it's just kneejerk "cloudflare = bad".
palata 6 hours ago [-]
> makes me think it's just kneejerk "cloudflare = bad".
I mean, sure. There is that against BigTech all the time, and I understand where it comes from.
What I don't get is that... I don't know, I feel like it should be possible to be against the fact that there are monopolies and criticise them on the one hand, and on the other hand to actually have technical discussions about technical solutions. Here it feels like many comments denigrate Cloudflare without even understanding what the OHTTP gateway does.
For example:
- "Google sucks, they just optimise for profit like all BigTech and that makes it worse for everybody" -> criticises a monopolist entity, all good. No need to be constructive here, it's just sharing a feeling.
- "Android's security model is soooo bad because Android is developed by Google, you should use Linux on mobile it's a lot more secure" -> criticises a technical solution (Android's security model) in a completely uninformed manner, not good.
In other words, BigTech companies "suck" by being BigTech companies, but they do hire brilliant engineers and develop nice stuff (when they don't develop technology to screw us, that is), and I think it would be worth acknowledging that. Cloudflare does contribute a lot of cool stuff open source. One doesn't have to like that Cloudflare is as big as it is, but that's not a reason to say that what they open source is bad software.
ThatMedicIsASpy 13 hours ago [-]
You want to say the intelligence agencies are the biggest protectors of piracy (Piracy websites love Cloudflare)?
evulhotdog 12 hours ago [-]
The way I look at it is more like civil vs criminal.
Yaqub_W 15 hours ago [-]
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? :)
simondotau 15 hours ago [-]
I dare say that Cloudflare would represent excellent value for money to the intelligence agencies.
nullbio 13 hours ago [-]
And Google. And Apple. And Microsoft.
simondotau 13 hours ago [-]
Less good value though. Cloudflare is currently 1/20th the valuation and is actively operating as a MITM attack on half of the internet.
brookst 13 hours ago [-]
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?
burdock 7 hours ago [-]
Cloudflare Proxy, which is required for their ddos protection - and which as I recall accounts for like half of internet traffic - handles TLS termination at CF servers.
When you capture traffic at internet backbones, which the NSA does (Room 641A), you don't get to middle-man the encrypted traffic. Cloudflare gets access to unencrypted traffic, because they act as the TLS termination.
Most companies take this trade-off because "we can trust cloudflare", or "the data isn't that important, and besides it's encrypted the rest of the way anyway."
0x073 17 hours ago [-]
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.
But maybe I get privacy wrong.
johnhess 11 hours ago [-]
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.
thayne 9 hours ago [-]
For a single transaction that's great. The problem is whene a large fraction of the internet is served by a single entity (say cloudflare), then that entity has information about what sites/customers were visited by a specific ip address, and which ip addresses visited a certain site/customer.
Although, that is still better than them having the source ip and the content.
krzyk 12 hours ago [-]
There are other CNDs, and Cloudflare isn't event the largest one, it has best marketing and free solutions.
jbverschoor 11 hours ago [-]
Cloudflare provides so much more than just CDN, and in a very nice package
someonebaggy 14 hours ago [-]
Why not both? When browsing Microsoft, give your IP to Cloudflare. When browsing Pouet, give your IP to Pouet.
ThatMedicIsASpy 13 hours ago [-]
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.
stubish 3 hours ago [-]
If a human was manually reviewing your logs, maybe. But that isn't the problem. Your stream is already a pile of garbage amongst billions of other piles of garbage. Programs will find the keywords they are looking for no matter if they are looking in a big pile of garbage or small.
charcircuit 7 hours ago [-]
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.
> 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.
kccqzy 12 hours ago [-]
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.
gsnedders 2 hours ago [-]
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.
scosman 13 hours ago [-]
I’ve wanted this for a while. I make private desktop software for transcribing meetings. It’s essentially offline, but things like checking for updates require the network. I looked at ohttp but it was still private, and ended up pinging GitHub releases directly.
There’s also room for a privacy-centric analytics offering
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?
FridgeSeal 2 hours ago [-]
“Well you see, it’s better because of the fact the _we_ do it!” - Cloudflare, probably.
AtNightWeCode 8 hours ago [-]
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.
Joker_vD 18 hours ago [-]
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)...
15 hours ago [-]
someonebaggy 14 hours ago [-]
You already can't do that since the abuser will just buy residential proxies.
lgeek 14 hours ago [-]
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.
jasomill 11 hours ago [-]
Isn't the point of residential proxies to spread traffic accross a large number of IPs to avoid "persistent abusive" traffic from any single address or subnet?
esseph 5 hours ago [-]
> I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.
If you work for an ISP you'll see it all the time. It's a constant fight to keep your subnet reputations high, which is hard when the subscribers don't care unless you shut off their service, but then your IP block still has a reputation issue to clean.
yencabulator 10 hours ago [-]
Banning a couple of faraway datacenters by ASN (and thus IP address) took out like >80% of the bot traffic to a site I help. They won't "just".
Joker_vD 14 hours ago [-]
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.
someonebaggy 12 hours ago [-]
I have a public facing website that is blocking about 500 obviously botted requests per second. About half are from residential proxies.
ZiiS 17 hours ago [-]
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.
palata 11 hours ago [-]
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?
shieldagent 12 hours ago [-]
OHTTP is a neat split: the relay learns who you are, the gateway learns what you ask, and neither gets both.
arisudesu 7 hours ago [-]
Lots of words about how site owners can enable this "thing". But is it true that they can toggle it off at any moment? How as a visitor can I know in advance, whether OHTTP is enabled for my request and prevent making it, if OHTTP is not available?
GalaxyNova 5 hours ago [-]
Cloudflare is like the systemd of the internet
jt2190 14 hours ago [-]
> 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?)
9dev 14 hours ago [-]
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.
carlosjobim 14 hours ago [-]
"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.
stogot 14 hours ago [-]
Reading between the lines: privacy regulaton?
freedomben 12 hours ago [-]
> Customers will be able to enable our new OHTTP Gateway as a paid add-on to their zone and start receiving OHTTP traffic with just a few clicks.
I love to see privacy improvement in tech. However I do wonder at this. Cloudflare is obviously a business and can't do everything for free, but charging extra for websites to add privacy Seems like a poor incentive if the goal is to improve privacy generally
tclancy 11 hours ago [-]
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.
dokyun 20 hours ago [-]
SSL added and removed here :-)
cpa 18 hours ago [-]
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.
robertlagrant 14 hours ago [-]
This is slightly worse than Cloudflare's usual excellent writing.
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?
blantonl 13 hours ago [-]
I'm seeing more and more organizations that I neither can identify nor pin down now using more and more cloudflare privacy offerings to "hide" their intentions.
I respect customer privacy. But I also need to know who is abusing my platforms as well. The balance here is very difficult to manage, now that we have entire agentic platforms capable of deploying highly technical capable "abuse" platforms.
deknos 11 hours ago [-]
how can i run this for my friends and me selfhosted? is there a ohttp server?
palata 10 hours ago [-]
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?
maayank 9 hours ago [-]
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
singpolyma3 16 hours ago [-]
If sharing your IP address with a website is a privacy concern we need to fix that problem, not hide the IP addresses
fr2029 16 hours ago [-]
[dead]
20 hours ago [-]
BatchJob 7 hours ago [-]
Im at a loss as to what I or anyone else would actually use this for. But it is slightly creepy. Ill give it that.
palata 5 hours ago [-]
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.
indeyets 20 hours ago [-]
Has strong TOR (Onion Routing) feeling
arshxyz 19 hours ago [-]
> 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?
keel_dev 11 hours ago [-]
[flagged]
42droids 23 hours ago [-]
Next step: ClInternet: the World Wide Web by Cloudflare. :)
chairmansteve 22 hours ago [-]
"Jesters do oft prove prophets".
- King Lear
pbhjpbhj 16 hours ago [-]
"Ful ofte in game a sooth I have herd saye!" (Chaucer, The Cook's Tale)
LoganDark 15 hours ago [-]
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!
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.
adlotsof 22 hours ago [-]
Not sure how north korean hackers benefit from not knowing who is accessing their servers?
14 hours ago [-]
roozbeh18 21 hours ago [-]
We have Cloudflare Tunnels to thank for this. I wish Cloudflare did more to stop malicious use of Cloudflare Tunnels.
est 20 hours ago [-]
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.
therein 22 hours ago [-]
I think you misunderstand. This is for inbound traffic, not outbound.
mococa 13 hours ago [-]
They really want to be MITM
gruez 9 hours ago [-]
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).
ranger_danger 22 hours ago [-]
Does any current proxy/tunnel/VPN software support OHTTP as a transport method?
What about browsers making general website requests to services that support it?
jon-wood 19 hours ago [-]
iCloud Private Relay (available on every macOS and iOS device in recent years) uses OHTTP to obscure your identity from sites you visit.
ranger_danger 9 minutes ago [-]
Yes, but that shifts the trust even moreso onto Apple, and now they know every site you visit AND can see all your unencrypted traffic from their servers, and can associate that traffic across multiple devices/accounts/IPs with it.
Collusion between the relay and gateway is exactly the situation they warn breaks the privacy features of OHTTP.
And while some might think "well Apple controls the whole OS, they can always spy on you"... yes, but I'm operating under the assumption that they're not currently doing this, and that collecting data at the relay level may be easier/more desirable/discrete for them.
Naru41 22 hours ago [-]
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.
jon-wood 19 hours ago [-]
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.
Whether they abide by that is another matter.
Also the NSA is a "signals intelligence" agency... Wouldn't the FBI be the local analog to the CIA? Or maybe the DHS?
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?
Yeah I'm not sure what everyone's complaining about. The lack of criticism of anything specific about OHTTP makes me think it's just kneejerk "cloudflare = bad".
I mean, sure. There is that against BigTech all the time, and I understand where it comes from.
What I don't get is that... I don't know, I feel like it should be possible to be against the fact that there are monopolies and criticise them on the one hand, and on the other hand to actually have technical discussions about technical solutions. Here it feels like many comments denigrate Cloudflare without even understanding what the OHTTP gateway does.
For example:
- "Google sucks, they just optimise for profit like all BigTech and that makes it worse for everybody" -> criticises a monopolist entity, all good. No need to be constructive here, it's just sharing a feeling.
- "Android's security model is soooo bad because Android is developed by Google, you should use Linux on mobile it's a lot more secure" -> criticises a technical solution (Android's security model) in a completely uninformed manner, not good.
In other words, BigTech companies "suck" by being BigTech companies, but they do hire brilliant engineers and develop nice stuff (when they don't develop technology to screw us, that is), and I think it would be worth acknowledging that. Cloudflare does contribute a lot of cool stuff open source. One doesn't have to like that Cloudflare is as big as it is, but that's not a reason to say that what they open source is bad software.
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?
When you capture traffic at internet backbones, which the NSA does (Room 641A), you don't get to middle-man the encrypted traffic. Cloudflare gets access to unencrypted traffic, because they act as the TLS termination.
Most companies take this trade-off because "we can trust cloudflare", or "the data isn't that important, and besides it's encrypted the rest of the way anyway."
But maybe I get privacy wrong.
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.
Although, that is still better than them having the source ip and the content.
I have a feeling that privacy is easier to protect if you just mix what you want to hide with a lot of garbage.
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.
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.
There’s also room for a privacy-centric analytics offering
https://github.com/scosman/Biscotti
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.
If you work for an ISP you'll see it all the time. It's a constant fight to keep your subnet reputations high, which is hard when the subscribers don't care unless you shut off their service, but then your IP block still has a reputation issue to clean.
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.
I love to see privacy improvement in tech. However I do wonder at this. Cloudflare is obviously a business and can't do everything for free, but charging extra for websites to add privacy Seems like a poor incentive if the goal is to improve privacy generally
You can google the sentence directly to find it.
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?
I respect customer privacy. But I also need to know who is abusing my platforms as well. The balance here is very difficult to manage, now that we have entire agentic platforms capable of deploying highly technical capable "abuse" platforms.
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.
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?
- King Lear
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!
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?
Collusion between the relay and gateway is exactly the situation they warn breaks the privacy features of OHTTP.
And while some might think "well Apple controls the whole OS, they can always spy on you"... yes, but I'm operating under the assumption that they're not currently doing this, and that collecting data at the relay level may be easier/more desirable/discrete for them.