Stop Using Cloudflare

1. It is a GIANT man in the middle - MITM.
2. Their DDOS protection is not that good.
3. You are contributing to a centralized Internet.

@jonn @selea How can they know your user agent if they don't decrypt the SSL?

@qorg11 @selea

I didn't care too much for cloudflare until I read this.

That's kind of huge though. I can't wrap my head around why is this the only architecture possible, but if someone would pitch me the idea of MITMing their users, I'd say that it will never fly.

Intuitively, it's just not a valid SaaS model. I'd say that they're better off selling their classifiers for active use inn their customers' load balancers.

But sadly the world is the way it is. :D

Follow

@jonn " can't wrap my head around why is this the only architecture possible"

Because what CF does it:
- receive request from client.
- decrypt request.
- checks whether it's a "malicious one" or not.
- forwards request to origin.

Due to the protocol works, they *need* to decrypt the traffic to check it's content and check whether it's legit traffic or malicious traffic.

ยท ยท Web ยท 1 ยท 0 ยท 0

@finlaydag33k well, sure, but they could just as well sell NGINX modules that do it the other way around with the same latency, together with an active queue solution for operation under DDoS conditions.

Of course, MITM'ing is easier, but I'm genuinely surprised people subscribe to this MO.

@jonn That'd also become an issue because now CloudFlare doesn't know where to forward the data to (the "host" header is also encrypted when using HTTPS).
So then, the only way would be to directly forward the traffic to the server...
Which then has to _still_ process the traffic (both legit and malicious) at which point, the entire purpose of CloudFlare would be nullified.

@finlaydag33k forwarding packets are orders of magnitude cheaper than processing and the amount of roundtrips would be the same.

The only problem really is that it's not drop-in and has upfront expense of processing packets.

@jonn Well, think of it like this:
With CloudFail:
- CF receives
- CF decrypts
- CF checks
- CF forwards
- You process request

The first 3 steps don't cost the origin any resource at all.

Now imagine running it as an Nginx module:
- You receive (either with or without forward from CF)
- You decrypt
- You send to CF
- CF checks
- CF sends results
- You check results
- You process request

Now you have a few additional steps that *do* cost you resources in order to know whether to continue.
1/2

@jonn So basically you already did some grunt work in order to know whether someone is malicious or not...
So the attacker still wastes your resources.
They need a bit _more_ in order to take you out but still can take you out the same way.

CloudFail tries to prevent this by filtering *before* forwarding so your origin can spend all of it's time processing legit requests.

2/2

@finlaydag33k but in the current arch after "- You process request" comes you forward back to CF, who relays to the client, making it exactly the same amount of roundtrips except an extra reencryption step for the server (with O(1) processing, say, "strip request body").

@jonn You forget that roundtrips isn't the issue here, it's the fact that the origin can still relatively easily be attacked.
If your origin has to do any processing on malicious requests, the purpose of cloudfail is nullified.

Sign in to participate in the conversation
Linux.Pizza

A instance dedicated - but not limited - to people with an interest in the GNU+Linux ecosystem and/or general tech. Sysadmins to enthusiasts, creators to movielovers - Welcome!