I think this is a good idea as well. In their blog post they discuss how "Full SSL" is much better security than "Flexible SSL", but by not making it a requirement a lot of people won't bother with it.

"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM.

Only "Strict SSL" does, which makes sure it's a valid CA-signed certificate.

What we need (and what myself and others have requested) is Full SSL with fingerprint checking so you can keep security with a self-signed cert.

I honestly think CF should remove flexible SSL and full SSL as options - they're just too vulnerable to be valuable.

>"Full SSL" is still useless against an advanced attacker as it does absolutely nothing to prevent MITM.

I wouldn't say this is entirely useless, even if there is still risk. Someone can impersonate your site to Cloudflare's reverse proxy server if they control the medium between, but they can't just get instant plaintext. This adds an additional barrier for an intruder into Cloudflare's network: they'd have to not only tap all traffic, but inject their own self-signed cert as well. This increases the chances of Cloudflare discovering the intrusion.

I agree though that a pinning solution of some kind would be preferable.

Or public key pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-19

Yeah, if they supported that and showed you the fingerprint of the pinned key it may be workable. My worry with that is that few of the smaller websites would bother to validate it. Pasting a fingerprint in removes the need.

Will Cloudflare take any self-signed certificate in that scenario? I assumed you'd have to confirm the fingerprint (essentially pinning it) from within Cloudflare interface.

Currently in "Full SSL" mode they take any self-signed certificate. No fingerprint confirmation or even pinning.

I use CF on multiple sites and generally love it, but this is one of their biggest shortcomings - I still need to buy certs if I don't want to get MITM'd.

Can you elaborate on what the attack on Full SSL would be? If you give CF your self signed certificate over a private secure channel, why isn't that still secure?

That would be secure.

What they do is not secure. You never send them your public key, they simply try to connect to you take _any_ self-signed public key without performing any verification, allowing trivial MITM between them and your web server.

I would love to be wrong here, but please show me where you upload your public key. Last time I used full SSL at least there was no such option. No upload of public key or paste of fingerprint, they simply take anything your (or an attacker's) server provides on connection.

Ah. I haven't used the interface, and just made an assumption of how I thought would work (which I assume others may have as well). That does sound insecure.

Yeah, they _finally_ added Strict SSL which validates it with a CA at least, but still no free option if you want actual security.

Really hope they get there soon. Secure self-signed SSL to CF then free CA signed SSL to the internet would make this whole free thing a lot better.

What good would that do? A self-signed cert is about as secure as no cert at all. (Unless they implement their own form of certificate pinning for the origin, which would cause problems for sites with multiple certs on the same host, which is quite common)

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.