[JshWright]

The parent comment is reffering to the fact that they use CloudFlare to host DNS for the domains they control. That has nothing to do with the DNS resolvers their computers use (CloudFlare is certainly a reasonable choice there though... unless you don't use DNS at all, you have to trust someone)

[auslander]

Ok. But if they use Cloudflare, which MITMs traffic, all their users data is in plaintext to Cloudflare. Which leaks not only history, but also logins/passwords of site users.

My beef with CF is that I can not see which sites are behind CF.

[cyphar]

CloudFlare can be used purely for DNS -- in which case they are one of the better DNS services because they have an API that almost everyone supports.

But you are completely correct that running a CDN (HTTP or HTTPS) requires you to MITM everything. The same complaint applies to Akamai, Level 3, or any other CDN you can name. It definitely is a problem, but not one of CloudFlare's own making.

It would be a fair criticism of CloudFlare to say that they've made their defaults tend towards MITM even though it is very likely that most websites don't actually need a CDN -- meaning that they are MITM-ing more traffic than they need to. And they have had pretty bad bugs in the past that revealed large amounts of private data that was sent over TLS but was MITM'd by them[1].

I do agree that CloudFlare being so central to so many large websites is a problem though. I just don't agree that this discounts their use as a purely-DNS service.

[1]: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

[auslander]

I'm not alone, praise be. Lol :)

[CiPHPerCoder]

> Ok. But if they use Cloudflare, which MITMs traffic, all their users data is in plaintext to Cloudflare.

Using Cloudflare for DNS, and only DNS, doesn't subject you to this.

If you decide to use their reverse proxy features, then sure, the MITM criticism applies.

[leesalminen]

That's optional though, right? IIRC, you could still have SSL termination occur on your end but you lose tons of features which would require CF MiTM.

[CiPHPerCoder]

Yes, that's optional.

[Operyl]

Cloudflare has very specifically owned IPs and a number of tell tales to show that a site is behind it. Why do you have beef when it's practically dead simple to see that a site is protected by cloudflare. There's zero obfuscation.

[auslander]

Please, how exactly in browser I can see it?

[Operyl]

https://chrome.google.com/webstore/detail/claire/fgbpcgddpmj... https://addons.mozilla.org/en-US/firefox/addon/cloudflare-cl... Are two ways I found with a very quick Google search.

[auslander]

Well, thanks, but as I thought, its not that easy. First one is by CF themselves, no source :) Second is not used and not working. And nothing for Safari.

[Operyl]

Incorrect, the source is freely available, :).

https://github.com/cloudflare/claire

[qmarchi]

So some thing you can look for in a request:

  * `server: cloudflare` - Although CloudFlare uses a nginx, they report 
    themselves properly in the server header
  * `Cookie: _cfudid:*` - CloudFlare uses the cookie header to identify 
    users and prevent abuse. If you delete this cookie too many times,
    your IP is flagged by CloudFlare and you may receive an interstitial 
    blocking you from accessing a site.
  * IP Ranges: https://www.cloudflare.com/ips-v4 and 
    https://www.cloudflare.com/ips-v6 - CloudFlare owns the routing 
    to these IP addresses. If you want, setup some Firewall Rules to block 
    access to these ranges.

All in all, CloudFlare is probably the least of your worries. You might want to do some investigation on your ISP, some of which MITM and track any insecure content.

[nullify88]

> My beef with CF is that I can not see which sites are behind CF.

Sites behind CF usually include two headers in the responses: cf-ray and expect-ct.

If you see these headers, it's almost certain the response is coming from CF. So its likely those extensions are doing that, perhaps you might be able to verify the source code.

If the thought of connecting to a site hosted by Cloudflare absolutely disgusts you. Vist https://www.cloudflare.com/ips/ for a list of IPs that you can block.

[auslander]

Yes, thanks, I knew about headers and ips. Disgust is too strong word, aware is better :) some info may be sensitive and it goes in plaintext via CF. Its time to write my first extention, sigh.

[profmonocle]

All content delivery networks have this limitation. Not sure why you're targeting Cloudflare specifically.

[auslander]

No reason. Maybe because they have good PR and offer 'free' SSL, which many just take. I'm unaware of market size of other CDNs.

Do other CDNs offer free plans with SSL?

[JshWright]

That has nothing to do with someone's browsing history...

Seems like you just have an issue with CloudFlare, and will keep changing the subject.

[auslander]

CF is in unique position to aggregate decrypted data from all users of many websites, attracted by 'free' plan with provided SSL.

This is against the whole idea of SSL, a closed tunnel between users and websites, so yes, I have an issue.

Plus many users set their DNS resolvers to CF DNS, browsing history goes here.

[eropple]

Let's Encrypt effectively shoots a hole--and this is a good thing--in the idea that TLS is for a meaningful kind of identification and establishes once and for all that the primary reason for TLS is for secured communication across the open internet.

And...that's it. CloudFlare operates in this spirit. It does not route traffic from its edge nodes across the open internet. It routes it across its private network.

So, no, it's not against "the whole idea of SSL"; it's what you have decided the idea of SSL is and nobody else on the internet really agrees with.

The amount of disingenuity you're hucking in this thread is pretty gross and you should stop.