[feature suggestion] detect CF certificate for heightened MitM awareness

[ghost]

Suppose there is difference in CF (edge server) TLS traffic if the (shared) certificate is issued by CF (like the link you stated https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/) or issued by another CA like mozilla.org being hosted on CF but using their own (even EV) certificate.

Whilst in the former case it is rather likely that the TLS traffic terminates at the CF edge server and thus insinuates a higher MitM risk whilst in the latter case it is less likely that Mozilla is sharing its EV certificate key (and thus governing TLS traffic) at the CF edge server with CF, though there is not guarantee to it either.

What I am trying to point out is that it perhaps makes sense for the user awareness to differ whether a site hosted on CF is utilising a CF certtificate and thus presenting the lowest security level with regard to potential MitM.

N.B. If sites would deploy DNSSEC + TLSA (and clients to support same natively) the TLS traffic with any cloud provider would be way more transparent, but that is for another day..

[claustromaniac]

As far as I know, that's not doable on the current stable release due to API limitations, and it seems even the current nightly builds have very limited support for these things. :disappointed:

According to documentation, I would need to switch back to OnHeadersReceived in order to be able to implement something like this, which is not cool because:

1. it would mean killing off the most significant advantage that this fork has over the original Detect Cloudflare extension and...
2. I would be rolling back most of the small fixes that I already implemented here that depend on the OnCompleted event.

While I believe there are alternative (and surely more complicated) ways to fix those smaller issues, I intend to stay away from OnHeadersReceived until the devs at Mozilla fix the current compatibility issues caused by it. I would never use or recommend this extension if I knew for a fact that it could cause other (more important) extensions to malfunction.

All of that being said, your suggestion is good. If it ever becomes feasible I will have to do my homework and learn whatever I still don't know in order to implement it... and then I'll have to consider a bunch of things, but I will most definitely keep it in mind for the time being.

Thanks!

[claustromaniac]

Good news!

These bugzillas suggest that onHeadersReceived won't be necessary to implement this. :tada:

I'm going to try to test this one of these days. I still have to come up with a good way to present this information to the end users, but I guess I still have until 62 stable lands for that :sunglasses:

Initially, I think I'll stick to color-coding the icons/badge. I mean, if I currently use orange for non-CF-served page + CF-served external resources, and red for CF-served pages, I could use a new color for CF-served CF-certified pages. Like... uhh... purple... or black... or something.

There is plenty of room for improvements in the popup, so I'll probaby do something more to it, and I'll definitely have to improve the documentation too.

Anyway, I'm open to more suggestions/ideas if you have any.

_{@Thorin-Oakenpants, IF you use this thing, this is a good time for you to introduce your usual F'ing good nits. No pressure, though.}

[Thorin-Oakenpants]

I am indeed using this. I don't want to nit too hard, or too early ... Interesting point: because I sanitize protected pages, AMO didn't add me to your user counter. So at the time of writing, feel free to boost your numbers by one :)

To include two bugzillas in one link, use

• https://bugzilla.mozilla.org/buglist.cgi?bug_id=1322748,1474657 Or otherwise make it clear there are two links, I almost missed one of them

[ghost]

On a second thought I am wondering whether it makes sense to implement the idea condsidering that any of CF's TLS schemes are terminiating at their edge proxies:

1. flexible
2. full ssl
3. full ssl (strict)

For 1 and 2 it would be logical that the CF certificate is on display and perhaps also for 3 but for some reason on mozilla.org their EV certificate is in evidence, same for the link in the bottom half.

Is there another scheme or are those certifcates served seperately for (browser) appearance? In the traffic logs the CF headers are present and thus TLS traffic is proxied through the CF egde.

Hence the second thought of whether the certifcate type really matters in the end.

Mozilla for instance is not using CF edge for content that offers user authentication, e.g. on https://addons.mozilla.org

---

it is rather curious that Mr. Hunt in 2016 had some concerns about CF's SSL schematics but nowadays advocates it

https://httpsiseasy.com/

1 min and 20 sec into the 4th video it gets curious about MitM but he failing to mention that CF is exactly doing such...

[claustromaniac]

To include two bugzillas in one link, use

• https://bugzilla.mozilla.org/buglist.cgi?bug_id=1322748,1474657 Or otherwise make it clear there are two links, I almost missed one of them

Sorry, I guess TVtropes already ruined my life (they put consecutive links like that all the time). Thanks for the tip tho.

@n8v8R,

At first, it seemed strange to me too (CF-served mozilla.org having an EV cert issued by DigiCert?!?!), but after some investigation I think I've found the answer: https://www.cloudflare.com/ssl/dedicated-certificates/

If my understanding is correct, this means site owners can pay CF to get them to use their certs on their behalf, which in turn means none of the 3 schemes guarantee that Cloudflare itself is going to be the issuer of the cert. If that is the case, then I guess this really is a lost cause, but I still believe this is worth investigating more. 'Sides, I'm by no means an expert on these things, I could be wrong. There is no harm in leaving this issue open for the time being, in case anyone else wants to chime in.

it is rather curious that Mr. Hunt in 2016 had some concerns about CF's SSL schematics but nowadays advocates it

I guess it just means he trusts them, or he has some other sort of motivation. Have you ever heard of affiliate marketing? just saying. :wink:

[ghost]

Took me a bit by surprise that CF is actually a trusted CA but then looking into FF's Certificate Manager I discovered CF under the CA root of Baltimore CyberTrust Root.

Looking into the details/extensions of that trust certificate there seems some collaboration with DigiCert judging by

OCSP: URI: http://ocsp.digicert.com URI: http://crl3.digicert.com/Omniroot2025.crl Certification Practice Statement pointer: https://www.digicert.com/CPS

---

Quite interesting though:

Shorter physical distance between your certificate and your visitors results in enormous performance gains. Cloudflare distributes your certificates to our edge servers around the globe to significantly reduce the latency incurred during the TLS handshake.

Begs the question whether in such case the TLS still terminates at the edge server and gets re-encrypted (as in https://www.cloudflare.com/ssl/keyless-ssl). And I would reckon that is an answer hard to come by.

[earthlng]

Holy shit I didn't think my opinion of CF could get any worse. To me, reading https://www.cloudflare.com/ssl/dedicated-certificates/, it sounds like customers of that service hand over the issuing of certs for their "own" domains completely into the hands of CF, presumably in a malicious and deceptive attempt to trick visitors into thinking that they have a direct connection to the real server. Now instead of CF using their own CF certs to man-in-the-middle every connection they just use the make-believe mozilla EV cert or whatever to MitM connections to mozilla because CF are in full control of that cert including the private keys:

Dedicated SSL Certificates eliminate the burden of generating private keys, creating certificate signing requests (CSR), renewing certificates, revoking and reissuing after crypto vulnerabilities such as Heartbleed, and many of the other maintenance tasks associated with traditional SSL certificates.

oh the burden of generating private keys, etc :man_facepalming:

what a fucking shame that mozilla are taking part in that deceptive scam!! I guess the haters were right after all

[earthlng]

If you ever manage to detect this scam in your addon fork, I think a good default option would be to just completely block such domains for shameless deceptive behavior.

[ghost]

@earthlng What happens to the traffic after it enters the edge server is hardly detectable. And as such blocking CF hosted traffic is likely not the intention of this WX but rather raising user awareness. Each user can draw their own conclusion and whether to stay on such sites or leave.

There used to be a WX called Block Cloudflare MiTM Attack which got culled by Mozilla however...

[earthlng]

a good default option

[ghost]

I would reckon that CF's service portfolio might blurr the issue of MitM considering products like

1. DDoS Protection
2. Rate Limiting

which are basically firewall features and not necessarily imply/involve any MitM activity (thus be still considered safe) and yet a site deploying either of those might display a CF ip address (due to traffic routing) and perhaps even CF's response headers.

[claustromaniac]

...presumably in a malicious and deceptive attempt to trick visitors into thinking that they have a direct connection to the real server

@earthlng, that's what it sounded to me as well. And I actually interpreted those dedicated certificates the same way you did the first time around (I think), but you worded that a lot better. I was hoping it was just my impression, so I focused on staying relevant to the issue at hand, but it really does sound as shady as it can get. And Mozilla getting involved with them came as a bit of a surprise to me, but at least they're not idiots: they don't seem to be using CF's services for anything critical, at least at a first glance... We should totally keep our eyes peeled, though.

If you ever manage to detect this scam in your addon fork, I think a good default option would be to just completely block such domains for shameless deceptive behavior.

IF I ever manage to detect that reliably, sure... _^maybe. It doesn't sound feasible so far, though. There's just too much going on their side and we are given very little information to work with. It makes it seem like whatever criteria we can come up with will be inevitably arbitrary.

I mean, what I said earlier about mozilla.org was just a theory based on observation. Any decision based on such speculation would be arbitrary and, unfortunately, unless we get the help of like... the Cloudflare version of Edward Snowden, I doubt we'll ever know much. I'm afraid raising awareness is probably the best I can hope to achieve with a tool like this. At least the best I can hope to achieve without (fully) politicizing it. I feel I'm too small a cat to wage war on a massive enterprise.

BTW, do any of you people know what happened to the Block Cloudflare MitM attack extension? I mean, why was it removed from AMO? More importantly, is the creator still alive and free? Just kiddin' of course... although, Donald Trump did become a president... nothing can suprise me these days.

Anyway, at least now we know that we can't even trust whatever certs are in use whenever Cloudflare's headers turn up during requests for main documents... (awesome!)

yet a site deploying either of those might display a CF ip address (due to traffic routing) and perhaps even CF's response headers.

I haven't come across a single site with DDoS protection that didn't seem to be served directly by Cloudflare. Let me know if you ever do.

And yes, their portfolio definitely blurs the issue. They offer too many convenient services, and some of the most wanted ones they offer for FREE. It's no wonder they're so successful. If I were a web developer I would find their services too tempting to dismiss without some serious consideration, and being on the other side means it's not MY privacy and MY security that is at risk, it's my USERS'... who cares about them? 90% of them hand out their personal lives for free every day to just about ANYONE. F 'em. There's no saving them now. My convenience is worth more.

Yeah... Makes sense to me. Shit, I got carried away with the rant and I forgot to grab my tinfoil hat. BRB.

[ghost]

This is interesting https://www.bleepingcomputer.com/news/security/cloudflare-improves-privacy-by-encrypting-the-sni-during-tls-negotation/

as in https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-3.1

In Split Mode, the provider is not the origin server for private domains. Rather the DNS records for private domains point to the provider, but the provider's server just relays the connection back to the backend server, which is the true origin server. The provider does not have access to the plaintext of the connection.

---

suppose there is no way to detect shared mode vs split mode?

[claustromaniac]

That's interesting.

I'll have to check their documentation to see if I can find something that can be used to detect it from our side. If I do find something, I'll have to come up with some good way to present this information, but that's not an issue. If I don't find anything, I'll keep looking anyway. I may eventually find something on my own.

Thanks for the info.

[ghost]

https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/

This is brand-new technology and Firefox is the first browser to get it. At the moment we’re not ready to turn it on for all Firefox users.

set the “network.security.esni.enabled” preference in about:config to “true”). This should automatically enable ESNI for any site that supports it. Right now, that’s just Cloudflare, which has enabled ESNI for all its customers, but we’re hoping that other providers will follow them. You can go to: https://www.cloudflare.com/ssl/encrypted-sni/ to check for yourself that it’s working.