Self-signed cert is perfect when you can share it beforehand as CloudFlare users/customers could with CloudFlare through CloudFlare's panel. That way no one, not even a rogue CA, could forge it.

It's just probably too much effort for a small number of users who would go through the trouble. Or maybe not.

https://news.ycombinator.com/item?id=8382774

A self-signed cert at least prevents wiretapping. Even if there is a man in the middle only that "man" can get your data. Not great but a lot better than nothing.

> A self-signed cert is about as secure as no cert at all.

It protects enormously against a casual attacker who is able to sniff network traffic but not MITM you.

This is the nail-clipper defense. For cases where a terrorist might take over a plane by threatening to give people tiny cuts or jabs, taking away nail clippers 'protects enormously'.

How often have you encountered read-only network access? It doesn't happen in reality; even the middle hop in a route has total control over the flow of traffic and thus can terminate it and mitm on reconnect. In any case, confidentiality is next to worthless without integrity and non-repudiation.

> How often have you encountered read-only network access?

Public wireless points (i.e. Firesheep), any network with a hub instead of a switch...

None of those are read-only.

I don't recall ever being on a public hotspot that let me change its DNS settings to hijack other users' Facebook traffic.

DNS spoofing is the most trivial attack there is on a public hotspot. The 'dnsspoof' tool was packaged with DSniff over 13 years ago. Even if you don't directly spoof DNS, there's a bunch of ways to intercept or change DNS traffic on a public hotspot, like ARP, IP or access point hijacking. Any 'how to hack' book will cover it.

So long as CF pins the cert it's perfectly safe.

Like I said in my comment, yes, pinning the cert would be better. It wouldn't be PKI at that point, but it would be better than just accepting any self-signed cert.

But what is 'safe'? What are you actually trying to secure?

If you're trying to ensure that CloudFlare receives an authentic copy of data to deliver to users, a pinned self-signed cert will do that. If you're trying to also ensure that only the intended parties get the origin's data, this is not "safe".

In the current model, CloudFlare is the 'client' that requests resources from the origin 'server'. The client verifies its connection to the server is valid before requesting content, which is where a self-signed pinned cert would show that the client is who they say they are. But the server has not verified the client! The client could be anybody, like the NSA for example, and the origin server would hand over data happily. To fix that you'd need to also do client-authentication in the handshake. I don't know that they support that currently.

You're basically implementing public-key crypto using PKI infrastructure using two nodes. Can it work? Sure. Was it designed for this? No. Are they doing it 'securely' right now, for all uses of 'secure' or 'safe'? Not to my knowledge. Will they support client authentication in the future? Who knows.

For the vast majority of websites that do not currently use SSL client certificates, the NSA could also connect to the site normally via CloudFlare, which will happily proxy arbitrary requests to the origin server because that's the whole point. If you want to secure data, any higher level authentication system (HTTP auth, your standard form based account systems) will still work. No?

Correct. If you want to keep the data private, any authentication system would be better than none. It would be nice to encrypt the data too, and provide non-repudiation, which is what a secure connection is for.

Most CDN setups i've seen have never bothered with any of this because they pass no private data; it's all static resources, mostly. Even if they did pass private data, they just use IP filtering and completely ignore mitm. Then they don't address client authentication because IP spoofing is, like, totally hard.