
CloudFlare, We Have a Problem - joepie91_
http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/
======
rudolf0
Nearly everything in this post is FUD.

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.

~~~
Animats
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.

~~~
manigandham
_Every_ CDN is a MITM as a service. There are business benefits to that
service which make sense.

Yes CF has the "flexible SSL" option which is one of their risks but
ultimately it comes down to the person using the tool.

~~~
Animats
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.

~~~
manigandham
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.

------
knorker
tl;dr: This blog post is just misinformation.

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.

~~~
joepie91_
> 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.

~~~
manigandham
> 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.

~~~
detaro
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.

~~~
manigandham
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.

~~~
detaro
I'm not the person that first responded to you, I'm agreeing with you ;)

------
cpbotha
Thanks for writing this post.

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.

------
K0nserv
My follow up questions on this is.

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?

~~~
joepie91_
> 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.

~~~
K0nserv
> 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.

~~~
joepie91_
> 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.

What are you paying for S3, currently?

~~~
K0nserv
> ... 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.

------
espellcaste
Interesting read! Didn't know all of it about CF.

