The only accurate part is that Cloudflare is indeed a MitM no matter what SSL mode you have enabled. An intelligence agency that thoroughly compromises Cloudflare's interception points would be able to ignore SSL for a lot of large websites.
That's just a trade-off you have to decide is worth it or not before signing up.
I've commented on this before. Cloudflare is MITM-as-a-service. Think of it as a form of security theater. If you're going to use encryption, don't outsource your public key.
If you care about security, you need to bypass the CDN for login pages or pages that accept credit cards. All images, CSS, and Javascript should have subresource integrity hashes. Then content tampering is likely to be noticed by somebody.
No, that's a false way to start with "if you care about security" - Everyone cares about security, not doing what you say doesn't mean I don't.
There are different risks and tolerances for every business and different ways to deal with this. Ultimately everyone can be compromised from the ISP, CDN, web host or even the network equipment maker.
The vast majority of time, these other vendors will be much more secure than doing it yourself. If you accept credit cards, the last thing you should be doing is storing those numbers yourself, this is why we have PCI compliance and other certifications so that trust and capability can be measured and relied on.
This applies to all CDNs, and is part of what a CDN is. (if you think it only applies to proxying ones, then think about what I can do if I own your copy of jQuery)
If your threat model says you should not have a CDN, then don't have a CDN. This is not Cloudflare specific, and they are not even the biggest player! (e.g., not i.e., Akamai)
Don't get me started on the DDoS misapprehensions. "Just run your own" mitigation appliance to take XXX Gbps DDoS? This is a gross misrepresentation of what DDoS and DDoS mitigation is.
> This applies to all CDNs, and is part of what a CDN is.
Not really. The problem with CloudFlare is that it's not just your static assets going through it, but everything.
> (if you think it only applies to proxying ones, then think about what I can do if I own your copy of jQuery)
There are quite a few (in-progress and already-available) mechanisms to limit what third-party scripts can do on your page. All of that is bypassed when somebody injects code directly into your page.
> Don't get me started on the DDoS misapprehensions. "Just run your own" mitigation appliance to take XXX Gbps DDoS? This is a gross misrepresentation of what DDoS and DDoS mitigation is.
That specifically refers to when you have your own infrastructure, and conveniently ignores all the suggestions for the other cases.
> Not really. The problem with CloudFlare is that it's not just your static assets going through it, but everything.
Yes it applies to all CDNs. You can proxy whatever you want through them, including your main domain or just a subdomain for assets. There is nothing different here about CloudFlare.
Some CDNs can only serve static files and are not suitable to send the full page through them. But yes, nothing is stopping you from using a CDN like CF that could do so and use it just for static files.
Those are just legacy old CDN's then. Every major CDN today is a reverse proxy service. This post about CF being some kind of MITM risk isn't applicable when they all do this to function, even for static assets too.
I was happily using cloudflare on two of my sites on webfaction mostly for the easy SSL (I did this before let's encrypt). Your post motivated me to try out let's encrypt via the acme.sh script in webroot mode: It took me all of 10 minutes to get and install LE's SSL certificates and change authoritative nameservers away from cloudflare.
I run my website from S3 behind CloudFlare. How can I achieve free SSL without involving my own servers to terminate SSL and having to maintain and rotate certificates say using Let's Encrypt?
> I run my website from S3 behind CloudFlare. How can I achieve free SSL without involving my own servers to terminate SSL
You can't, at least not without using a different service that works exactly like CloudFlare (which would obviously defeat the point). You probably shouldn't be hosting your site on S3 to begin with (this isn't what it's for, really), and you wouldn't have this problem in the first place.
> and having to maintain and rotate certificates say using Let's Encrypt?
Use Caddy, which does this all automatically without you even having to think about it.
> You can't, at least not without using a different service that works exactly like CloudFlare (which would obviously defeat the point). You probably shouldn't be hosting your site on S3 to begin with (this isn't what it's for, really), and you wouldn't have this problem in the first place.
I understand your point about CloudFlare as an intermediary for SSL not being ideal and I agree. On the S3 issue I quite strongly disagree, if you have a site that updates infrequently and can be compiled as static files S3 is one of the absolute best choices because it's cheap and requires you to manage no infrastructure at all. It is indeed one of the things it is for, they wouldn't have a public website checkbox if that wasn't the case.
> Use Caddy, which does this all automatically without you even having to think about it.
Again this has the prerequisite of maintaining infrastructure which needs to be kept up to date and secure. It's also massively more expensive than S3 for my use case.
> S3 is one of the absolute best choices because it's cheap and requires you to manage no infrastructure at all
... and there is no possibility of ever having proper TLS, with or without CloudFlare. That alone disqualifies it as "best". It simply doesn't meet minimum requirements.
> Again this has the prerequisite of maintaining infrastructure which needs to be kept up to date and secure. It's also massively more expensive than S3 for my use case.
> ... and there is no possibility of ever having proper TLS, with or without CloudFlare. That alone disqualifies it as "best". It simply doesn't meet minimum requirements.
I'd argue that using CloudFront for SSL termination would be slightly better, but ultimately even just running an EC2 instance implies trusting Amazon and giving them power to intercept and mess with your traffic. So I guess with CloudFlare the only difference is you are trusting one more entity that could screw you over. So you end up trusting both Amazon and CloudFlare.
> What are you paying for S3, currently?
I pay roughly $0.03/month so switching to something like a DO droplet($5/month) would increase cost by 16566%, increase labour required and make the site less stable and more vulnerable to hug of death scenarios.
It's not just S3 though. Lots of not-quite fully-featured services like App Engine, GitHub pages, and Heroku benefit from Cloudflare's SSL and other configuration options. For many use cases security is a tradeoff, and trusting one more US-based company can be worthwhile for both users and site owners.
Setting up your own Ubuntu instance on DigitalOcean (or similar) along with Nginx and Let's Encrypt certificates is cheap and easy to do. I can't figure out why people use GitHub Pages for hosting static pages for their projects, without end-to-end encryption. It's actually quite a problem, given libraries are a primary target for malware. And if you can work with Git, then you also can also do "apt install nginx".
The best part about a VPS is that you can do more things with it, like having your own VPN, or XMPP server. And the web is full of step by step tutorials.
And you may invoke the convenience of it, but that convenience comes with a broken security model.
AWS do free SSL certificates via their certificate manager service now, it works via cloudfront their own CDN (as well as other services) which can use s3 as a back-end
The only accurate part is that Cloudflare is indeed a MitM no matter what SSL mode you have enabled. An intelligence agency that thoroughly compromises Cloudflare's interception points would be able to ignore SSL for a lot of large websites.
That's just a trade-off you have to decide is worth it or not before signing up.