Add an option to stop trusting Cloudflare certificate #1743
Comments
|
Thank you for this report. This is interesting and will take some time to read and discuss. |
|
I suggest you close this as invalid. Most CF users will use the flexible HTTPS-option and will not have own SSL certificates. In addition, CF also issues individual certificates to paying members and they use trusted CA signers. Doing this would impact millions of CF sites around the globe; it's clearly a crusade against cloudflare started by disgruntled TOR users about being challenged by CF's captcha policy for TOR traffic and has no valid background other than political. |
|
@wolfbeast Did you read all texts? It's just not about captcha issue. It's about MiTM and tagging. Your website, PALEMOON.org, use cloudflare so you're on MiTM side. People, please read all text before making decision, don't jump to anti-Tor side just because you're using their service. |
|
Nonsense. ANY CDN that uses https is a "MitM". It is up to website owners to decide whether this is something they trust the CDN with or not, and it is not the task of clients to arbitrarily start censoring the net based on which CDN is in use because the CDN happens to have a rule in place to challenge TOR or any other known-suspicious traffic. Because that's what being asked here. |
|
Rather than the website owners to decide, it should be up to the website consumers. Having a flag to permit or notify of MITM techniques is a valid way to protect the users. Allow the clients to decide what they trust. |
|
As the reporter of Tor Bug 24351, as well as the creator of a new repository for developing a Cloudflare-blocker add-on, I ask to make a fair response to this calumny by @wolfbeast:
Correction: Cloudflare’s Internet-scale mass-MITM attack impacts the visitors to millions of sites around the globe. Anybody who deems that to be “no valid background other than political” betrays a lack of understanding of TLS, its architecture, and its security guarantees. And my “crusade against Cloudflare” has substantially nothing to do with Cloudflare’s CAPTCHA policies, odious as those may be. Only the timing of my Tor Browser bug report was indirectly motivated by that latter issue, insofar as Cloudflare is trying to coerce Tor Browser to bundle third-party code to avoid CAPTCHAs. Cloudflare should be blocked; yet ironically, they are demanding that others jump through hoops to get unblocked by Cloudflare. Just who do they think they are, the owners of the Internet? Oh. But the substance of my complaint is concern for privacy and security. Period. Those of us who spent decades urging an encrypted Internet somehow awoke one morning to find that most of the Web is encrypted—and much of it is being decrypted at a single, centrally-controlled chokepoint. That is not an improvement. In some ways, it’s even worse than the situation in the 90s. I don’t really care too much about Cloudflare’s tormenting of Tor users with CAPTCHAs. Repugnant though that may be in principle, it doesn’t really affect me too much; I try generally to avoid Cloudflared sites, and the CAPTCHA wall actually helps in that regard. I do care about the lock icon on my browser. I want for it to stop lying to me. Part of the problem with Cloudflare is that in normal web use, it’s invisible: Nothing even tells the user that there is an active MITM attack in progress. The browser must immediately cut the connection when it detects any MITM attack; but it should permit well-informed users to override this behaviour, just as it does with unverifiable certificates. Of course, the only sane security policy is default-deny. In sum, I want to make one thing absolutely, excruciatingly clear: My substantial opinion of Cloudflare would not change, even if they permanently whitelisted all Tor exits and stopped all CAPTCHA use forever. My substantial opinion of Cloudflare may change, if and only if they were to stop MITMing TLS. Thank you for your time. Please consider giving your browser’s users the tools to make informed decisions about whether they want to expose their web traffic to Cloudflare. (P.S., for the record, I notice that Pale Moon completely nuked its equivalent issue. Classy.) |
|
FTR: The issue on Pale Moon was nuked by GitHub, not by Pale Moon devs (we don't have that power). Most likely due to the nature of the accounts that opened the issue and commented on it. Bottom-line is that CloudFlare is a CDN, chosen by website owners. Like other CDNs serving websites, website owners choose to use this service to improve the user's experience and provide DoS protection for their (origin) assets, often against payment. There is no MitM "attack" of any kind, because the CF servers are a consciously-chosen part of the website's used web-infrastructure. What's next, an issue gets opened to block all BlueHost-hosted websites because someone doesn't agree with their use of CPanel? There is no reason why this should be treated as a certificate trust issue, or any issue at all, for that matter. |
|
@wolfbeast Very funny. I remember you closed and locked that issue. It's easy to nuke issue if you guys contact github to remove it from your repository.
OK Palemoon Browser developer, @wolfbeast, Explain how Cloudflare detect my UserAgent and header data without TLS decryption. Looking forward to your reply. |
ghost
mentioned this issue
|
The correct title of this issue should be "Add an option to block proxied MiTM attack" @wolfbeast Here's an easy description for ELI5. You're above 5, right? Let's just say you are an American. A few days later, you received a phone call from a friend. You --- [Post office, USA] --- [FBI] --- [Post office, Canada] --- Friend Here, Back to Cloudflare's story. I want to visit your website, "https www.palemoon.org" , securely. The browser is showing GREEN pad lock, this promise the user that the connection Me --- [ISP(can't read by TLS)] --- [your server] However, this is FALSE. Browser is LYING. Me --- [ISP(can't read by TLS)] --- [Cloudflare(read everything)] --- [your server] Cloudflare is a decryption facility. This is a clearly MiTM attack. Do you understand the danger? |
|
"But we are using Cloudflare's FULL certificate option. Only we can decrypt the packet" User --TLS-- [ISP(can't read)] --TLS-- [Cloudflare] --TLS-- [Origin server] "Cloudflare edge node (the Session Server) decrypts, inspects, and processes the original request." "If you want HTTPS on the backend connection to your origin server(s) CF does support it. |
|
@wolfbeast i understand your argumentation that it is not a MITM if the CF is a consciously-chosen part of the website but what really matters is what the user expects and wants. As a browser developer you should know that and you should try to protect the user whenever possible. and just because this is the way CDNs work doesnt mean it desirable in any way. this issue is about giving people the choice to opt out of surveillance at their own responsibility. the fact that you seem to be opposed to this casts a pale light on your browser that i actually considered using on a regular basis a few times. |
|
Firefox bugzilla |
|
oh, nice, the removed posts are suddenly back. |
|
@elypter Are you talking about my posts? Yeah I got flagged by @github so I sent angry email and my posts are back. Take a look at: |
|
wow, thats really shitty behavior |
ghost
mentioned this issue
ghost
mentioned this issue
|
This Anti-MITM addon is doing great job by redirecting to alternative website which don't use Cloudflare. |
|
Wouldn't a better solution be to detect IP address ranges 104.16.0.0/12, 2400:cb00::/32, and their secondary ranges? |
First part is inherently and indisputably true. Second part is absurdly ridiculous because a client tool inherently and irrefutably serves the user of that tool. A client tool that fails to look after the interests of the master it's serving is a recipe for disaster. I'm not going to install a tool that serves someone else.
That's sensible but it's a bit of a false dichotomy to say we cannot have both. We can (and should) live and let live. Let the website owners do whatever stupid shit they want to do with their websites, and also let the user client tools serve them to detect and avoid the dodgy CloudFlare sites.
Yes, but let's not overlook the fact that it's naïve website owners making that choice. To be clear, when I say naïve I mean that owners of most ClownFucked websites have no idea they are causing collateral damage to non-malicious Tor users, have no idea the TLS terminates at CloudFlare and gives CloudFlare a view on all traffic including unhashed passwords. CloudFlare probably covers their ass with a lot of fine print -- which isn't read by website owners who then continue to operate in total ignorance. I don't have a scientific study for that - it's anecdotal. I'm always surprised at how many website owners are unaware of those basic facts.
It should be pointed out that CloudFlare CAPTCHAs do us a service. They help us identify sites that should be avoided anyway and I am grateful for them. My first knee-jerk encounter with them caused me to nag website owners to whitelist Tor. I later realized that's destructive because it expands the deception of safety and usability to Tor users, which then leads to Tor users giving traffic (and thus business) to CloudFlared sites. Of course an add-on that looks for
Where did that add-on go? Superficially it looked like an interesting tool. The problem with CloudFlare15 privacy-abuse issues with CloudFlare: https://github.com/privacytoolsIO/privacytools.io/issues/374#issuecomment-460077544 |
|
@libBletchley
Isn't that exactly what I said? Operative keyword in my statement is arbitrarily. Oh, and please don't call all CloudFlare users naive. They aren't. Instead, consider the proposal in this issue naive because you're suggesting a wallpaper solution for something that requires content-based, not distribution-based, granularity. What's next, asking for an option to detect and block all websites hosted in a specific datacenter you don't trust? Or a specific country like the USA that performs surveillance? Who will determine what qualifies as a "bad distribution channel" or "bad origin" for me in that case? See where I'm going? Bottom line: Building in an Anti-CF option into the client is not attacking malicious content or "keeping the user 'safe'" from such content; it is an anti-competitive act against one specific CDN. And that is not something that belongs here, period. |
Not in the slightest. I said give the end user control over their own assets and experience (the OP's checkbox). You advocate the opposite: not adding the proposed checkbox, thereby inhibiting user control.
That's incorrect usage of "arbitrarily". The OP proposes giving the user the ability to specifically (and equally) treat the cert of all websites compromised by a particular CDN.
You tell us -- this your advocacy not the OP's.
Again you are misusing "arbitrarily". The rationale was enumerated in the same msg you responded to.
If the user were to have the option to selectively distrust other CDNs that's fair enough.
That's not correct because CloudFlare has a set of privacy abuses that's entirely a superset of many other CDNs, and perhaps a subset of others (depending on whether the user views outright Tor blocking more or less of a privacy abuse than Google's reCAPTCHA). The privacy abuses differ and so does the threat model of each user.
I didn't simply call them naïve, I actually detailed what information they lack which you failed to address.
First of all it's a false dichotomy to suggest it must be one or the other. There are privacy abuses in the distribution context as well as the content context and users should have control to mitigate both kinds.
Sounds like a slippery slope argument.
The end-user of course. The user whose assets execute the app.
Then you've taken the wrong stance. The OP advocates for giving users the choice.
This is another false dichotomy. Satisfying a user's need for data and also doing so in a way that's aligned with their ethical and political viewpoints is not contradictory.
First of all you've failed to establish that. But also an anti-CF option is motivated by more issues than malicious content. Malicious content is just one of the problems and it's only speculative.
You seem quite loyal to CloudFlare to go as far as to absurdly assume users opposing CloudFlare's privacy abuses actually have a business interest in CloudFlare's competitors and are secretly motivated by that. |
|
Problem is that Cloudflare isn't just another CDN. Throughout the years they have not only had various serious vulnerabilities but also are well known for providing safe harbor for some of the worst stuff on the web. I tried Cloudflare on a throwaway subdomain and it promptly gave me a certificate shared with a scam website. |
|
To be perfectly clear, I'm not advocating for CloudFlare. The advocacy here is clearly from the people in this issue pushing for unequal treatment against CloudFlare, throwing terms in the mix like websites being "compromised" by CloudFlare, which, once again, is not true. It is purely the webmaster's choice to use them or not. There is nothing "compromising" these websites. But I guess that message is still not getting through. I'm not going to keep repeating myself so after this post I'll leave you to make up your own dam mind on the subject. Please don't @dxgldotorg |
Effectively you are. Most of your comments in this thread contradict this statement.
Unequal treatment is appropriate, and justified by unequal service. Most particularly w.r.t. CloudFlare's attack on network neutrality. It's laughable to create access inequality and then expect equal treatment.
Of course it's true. The problems with CloudFlare post is littered with compromises.
Because you said "purely" it's a patently false statement. Website visitors have a both the right and the power to boycott CloudFlare; the user's choice is irrefutable. If both the webmaster and the user do not mutually agree to use CloudFlare or mutually agree to avoid CloudFlare, they're not doing business in the private sector. The only exception is in the public sector. If the webmaster is a government service and a citizen/resident/taxpayer is forced by the government to use CloudFlare only then may your statement be true in that bizarre and isolated context.
Again, you still continue with this blanket statement without addressing the compromises itemized in the problems with CloudFlare post.
Of course if you don't address the points that have been raised you aren't going to make any progress. All of your points have been defeated and you've neglected to address the issues.
I didn't see where @dxgldotorg demanded gratis service. Gratis service is of course part of the problem. This is what has enabled them to centralize 10+% of the web, dictate non-negotiable terms, and take a seat on the FCC's Open Internet Advisory Committee to influence legislation against net neutrality. The gratis service also raises the question about how they are monetizing all that data they see and collect. |
|
@libBletchley in my last comment I mentioned the hazard of shared certificates where a legitimate website can be quite easily bundled with a fraudulent, malicious, or illegal website with no recourse but to pay for the privilege to not have these bad neighbors. |
|
@dxgldotorg Whether it's actually is risky is a separate matter. As far as I can tell the risk is negligible, but perhaps I'm overlooking something. So to walk through this, suppose a visitor of a nefarious cert-shared website executes dodgy javascript from that website. The dodgy j/s could not decrypt the traffic coming from a visitor of your legit website because only CloudFlare holds the private key to do that. And going the other direction is also not an issue because each visitor has a unique key pair. If the asymetric crypto were used for signing things, then there could be a problem because the dodgy website could sign something as coming from your legit site, but AFAIK web SSL is used exclusively for crypto. |
problem with the original requestIt's worth noting that distrusting CloudFlare certs to the extent of not using them is a bad idea. Even if you distrust CloudFlare you still probably also distrust all MitMs that would sit between you and CloudFlare. So if you (foolishly) choose to feed info to a CloudFlare website for whatever reason it still makes sense to trust the certificate itself so at least you have a tunnel to CF. better approachA better proposal would be to trust the cert but replace the padlock with something that indicates that the endpoint is as untrustworthy as cloudflare. I suggest a clown head icon mounted over top of a padlock. A clown head with a metallic "∩" bend would be an intuitive way to express that you've secured a tunnel to a dodgy endpoint that's not controlled by the entity that the URL would seem to indicate. Or if a clown head too explicitly expresses that the user is clownfucked then replace the padlock with CloudFlare's cloud logo with a little metallic "∩" above it. |
|
@libBletchley
would look good for any mitm no only crimeflare |
Not all CDNs have as reckless of a MITM system as Cloudflare; don't many CDNs provide significant control over the infrastructure to their customers? But the idea still sounds good. |
|
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Just noticed it marked stale so was reminded. Some things to note are the following: In addition, higher tier paid accounts can upload their own certificates, thus detecting Cloudflare needs to be done by IP address instead to be reliable; Cloudflare does thankfully disclose all IP ranges assigned to them. |
Mozilla do not have a pair of ball to solve this problem. (there were at least 4 statements from Mozilla regarding this topic) |
|
A bit unrelated but chromium has an option to not trust certain certificate authorities. You can try opening chrome://settings/certificates and see the "Authorities" tab |
|
Also for desktop Firefox, you can distrust "Cloudflare Inc ECC CA-3", located under "Baltimore". But it will be ugly: HSTS makes Firefox prevent you from even temporarily allowing an insecure connection, which is another anti-user dark pattern, supposedly for preventing MITM attacks. You should always be able to override the browser's decisions, and the RFC only says "should" not "must". Edit: You can override it by inspecting the security warning page, and looking for the hidden "Accept the Risk and Continue" button, and remove the So now, Firefox does what I want. It warns me that a site uses Cloudflare. If I don't care, I will allow it. But if I care, i.e. a serious site like banking or government, I will complain. |
|
Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1802037 Change performed by the Move to Bugzilla add-on. |
Please consider adding a checkbox to reject website if it is using Cloudflare's certificate.
The reason is Cloudflare is very anti-Tor & anti-privacy company which collect your data to build a internet profile.
If you don't add this feature, I or other privacy activist can assume Firefox Klar is not a privacy app.
See:
https://trac.torproject.org/projects/tor/ticket/18361#comment:236
https://trac.torproject.org/projects/tor/ticket/18361
https://trac.torproject.org/projects/tor/ticket/24351
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831835
The text was updated successfully, but these errors were encountered: