Add an option to stop trusting Cloudflare certificate

[StopMITMInternational]

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

[pocmo]

Thank you for this report. This is interesting and will take some time to read and discuss.

[wolfbeast]

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.

[ghost]

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

[wolfbeast]

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. Just because I'm using their service doesn't mean I turn a blind eye to privacy/security; quite the opposite.

[MikeColes]

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.

[nym-zone]

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:

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.

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

[wolfbeast]

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.

[ghost]

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

There is no MitM "attack" of any kind

OK Palemoon Browser developer, @wolfbeast, Explain how Cloudflare detect my UserAgent and header data without TLS decryption. How Cloudflare target every single request without any decryption?

Looking forward to your reply.

[ghost]

The correct title of this issue should be "Add an option to block proxied MiTM attack" because it is not just about a certificate.

@wolfbeast AFAIK CPanel is just a management tool used by the destination server admin. Either you're a Cloudflare's lover or didn't read all texts above. Which one?

Here's an easy description for ELI5. You're above 5, right?

Let's just say you are an American. You want to send a confidential letter to your friend in Canada. You went to the post office with a sealed envelope .

A few days later, you received a phone call from a friend. "What's up?" "Did you send me a letter?" "Yeah." "It's already opened. Did you sealed it?" "What the..."

You --- [Post office, USA] --- [FBI] --- [Post office, Canada] --- Friend

Here, "sealed" is a promise that you want this letter opened only by a friend. It is breached by the middle point, in this case, FBI. It is safe to say that the letter's secure communication is BROKEN.

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 from ME and YOU(https://www.palemoon.org/) is completely secured.

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?

[ghost]

"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." https://www.cloudflare.com/ssl/keyless-ssl/

"If you want HTTPS on the backend connection to your origin server(s) CF does support it. Although your data is still temporarily clear within CF." https://security.stackexchange.com/questions/167172/is-cloudflares-ssl-half-baked-since-they-become-the-man-in-the-middle-mitm

[elypter]

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

[ghost]

Firefox bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1426618

[elypter]

oh, nice, the removed posts are suddenly back.

[ghost]

@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: https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor#ComputingTechnical "Github" section.

[elypter]

wow, thats really shitty behavior

[ghost]

This Anti-MITM addon is doing great job by redirecting to alternative website which don't use Cloudflare.

[dxgldotorg]

Wouldn't a better solution be to detect IP address ranges 104.16.0.0/12, 2400:cb00::/32, and their secondary ranges? This is because there are two custom solutions available, first is per-domain certificates rented from Cloudflare for $5/month/domain, and the second is that Business and Enterprise users of Cloudflare can upload their own certificates. Neither method enforces HTTPS from the origin, though the latter does make the installation of HTTPS on the origin much easier as the webmaster already has access to CA certificates.

[ghost]

@wolfbeast

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

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.

@MikeColes

Rather than the website owners to decide, it should be up to the website consumers.

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.

@wolfbeast

Bottom-line is that CloudFlare is a CDN, chosen by website owners.

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.

@nym-zone

My substantial opinion of Cloudflare would not change, even if they permanently whitelisted all Tor exits and stopped all CAPTCHA use forever.

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 cf-ray would be better than relying on the CAPTCHA, but at least the one I have rarely detects CF.

This Anti-MITM addon is doing great job by redirecting to alternative website which don't use Cloudflare.

Where did that add-on go? Superficially it looked like an interesting tool.

The problem with CloudFlare

15 privacy-abuse issues with CloudFlare:

https://github.com/privacytoolsIO/privacytools.io/issues/374#issuecomment-460077544

[wolfbeast]

@libBletchley

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

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.

Isn't that exactly what I said? Operative keyword in my statement is arbitrarily. Why would I want to install a tool that serves someone else, in this case someone (like you) who arbitrarily decides one actor on the Internet (CF) is bad and another isn't, but who serve the same purpose for the 'net? I might make the same point about Akamai, Cloudfront or other CDNs that also perform the same tasks, with the same kind of setup to serve content, to be enforced on all browser users. I'm sure all the "privacy issues" attributed to CloudFlare apply to any and all reverse-proxying CDN in existence, with the same conscious choices by webmasters to either use them or not for their presence and accessibility.

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? No, I'd like to determine for myself who I get the option to block or not, thank you very much - No bias and letting the user decide by way of their own actions (e.g. installing a content blocker of their choice) is always preferable over any bias imposed by the client vendor. What is the "interests of the users of a client tool", really? Is it to serve some kind of political agenda, or is it to provide web content to them?

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.

[ghost]

@wolfbeast

Isn't that exactly what I said?

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.

Operative keyword in my statement is arbitrarily.

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.

Why would I want to install a tool that serves someone else,

You tell us -- this your advocacy not the OP's.

who arbitrarily decides one actor on the Internet (CF) is bad

Again you are misusing "arbitrarily". The rationale was enumerated in the same msg you responded to.

I might make the same point about Akamai, Cloudfront or other CDNs that also perform the same tasks, with the same kind of setup to serve content, to be enforced on all browser users.

If the user were to have the option to selectively distrust other CDNs that's fair enough.

I'm sure all the "privacy issues" attributed to CloudFlare apply to any and all reverse-proxying CDN in existence

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.

Oh, and please don't call all CloudFlare users naive. They aren't.

I didn't simply call them naïve, I actually detailed what information they lack which you failed to address.

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.

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.

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?

Sounds like a slippery slope argument.

Who will determine what qualifies as a "bad distribution channel" or "bad origin" for me in that case?

The end-user of course. The user whose assets execute the app.

No, I'd like to determine for myself who I get the option to block or not, thank you very much

Then you've taken the wrong stance. The OP advocates for giving users the choice.

What is the "interests of the users of a client tool", really? Is it to serve some kind of political agenda, or is it to provide web content to them?

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.

Building in an Anti-CF option into the client is not attacking malicious content or "keeping the user 'safe'" from such content;

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.

it is an anti-competitive act against one specific CDN.

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.

[dxgldotorg]

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.

[wolfbeast]

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 @mention me in further replies.

@dxgldotorg So you expect CF to issue individual certificates and serve them for the free tier? If you don't want shared SSL, then get a paid account and upload your own certificate that doesn't share alt names with others. Alt names on a cert is hardly an issue of any kind.

[ghost]

To be perfectly clear, I'm not advocating for CloudFlare.

Effectively you are. Most of your comments in this thread contradict this statement.

The advocacy here is clearly from the people in this issue pushing for unequal treatment against CloudFlare,

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.

throwing terms in the mix like websites being "compromised" by CloudFlare, which, once again, is not true.

Of course it's true. The problems with CloudFlare post is littered with compromises.

It is purely the webmaster's choice to use them or not.

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.

There is nothing "compromising" these websites.

Again, you still continue with this blanket statement without addressing the compromises itemized in the problems with CloudFlare post.

But I guess that message is still not getting through. I'm not going to keep repeating myself

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.

So you expect CF to issue individual certificates and serve them for the free tier?

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.

[dxgldotorg]

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

[ghost]

@dxgldotorg Yes, I understand that. IMO it's wrong to fixate on the price and that was my point. If the cert sharing is risky then it should not be offered as an option full stop, regardless of whether it has a subscription cost or not.

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.

[ghost]

problem with the original request

It'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 approach

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

[4-FLOSS-Free-Libre-Open-Source-Software]

@libBletchley

cloud logo with a little metallic "∩" above it

would look good for any mitm no only crimeflare

[dxgldotorg]

@libBletchley

cloud logo with a little metallic "∩" above it

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.

[cxtal]

[stale[bot]]

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.

[dxgldotorg]

Just noticed it marked stale so was reminded.

Some things to note are the following: Today, Cloudflare is sometimes issuing Let's Encrypt E1 certificates to domains; not sure what triggers that instead of the Cloudflare certificates.

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.

[ghost]

it marked stale so was reminded.

Mozilla do not have a pair of ball to solve this problem. (there were at least 4 statements from Mozilla regarding this topic) Whoever still have interesting in this kind of topic better subscribe to you-know-where & visit IRC

[iambeingtracked]

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

[danuker]

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 hidden="" HTML attribute.

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.

[csadilek]

Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1802037

Change performed by the Move to Bugzilla add-on.