All I'm hearing is that Cloudflare allows their customers to configure client facing TLS without enforcing it upstream over the internet, providing a false sense of security. Thanks Cloudflare!
... and I'm pretty sure that their response will be "We are just a proxy, we are not responsible for anything".
@jgrahamc: Do you think it would be feasible to add clearer notification about potentially creating a false sense of security to the Cloudflare ui, when no origin SSL is present? What Cloudflare calls "Flexible SSL" has real implications and I think one of the necessary evils of infosec work is pushing people towards more informed decision making.
As a frequent Cloudflare freeloader and occasional paying customer (lots of different hats), I really appreciate how the service made it possible to use SSL for free, before it was cool.
With Let's Encrypt being implemented at a lot of hosting providers and hosting automation systems over time, I think the following may become a diminishing problem.
But in cases where, let's say, a "not top tier" hosting solution makes it impossible to use any sort of SSL/TLS back to the origin server (within the customer's budget), my personal choice has been to not defaulting/redirecting sites to Cloudflare's SSL.
And I mean, it's not like crappy hosting without Let's Encrypt automation or the ability to add Cloudflare's origin CA, is going away. One of Cloudflare's selling points at the low end, is how the service stretches the capabilities and resources of less than optimal hosting and apps. I mean, the idea of running Wordpress without Cloudflare or a similar service in front, really gives me the heebie jeebies.
Not going half-way with SSL is sort of an ethical choice for me, exactly for the reason of not wanting to give a false sense of security, even at the cost of Google juice.
I'm technically proficient enough to understand that client -> Cloudflare https connections can stop a lot of ISP/last mile/LAN level tracking and code injection, though. And obvioulsy, Cloudflare is a MiTM. So it's a real choice with tradeoffs.
But I work at a grass-roots level where I usually am the only person tangible IT skills. When it comes down to it, I feel quite strongly that we should avoid messing with people's already vague understanding of what that "green lock" means.
Presumably because some people have backends that don't support SSL (e.g. anything hosted on S3) and CloudFlare thought "eh, some encryption is better than nothing, and they're going to let us MITM their encrypted connection anyway so they're obviously not a bank or something really important"
it still is providing more security. yes it has a security hole, but for example if i'm in starbucks - you can't sniff out my cookies over the ssl encrypted traffic. Sure a backend provider can, but it's a layer of protection... I suppose an interesting question here is there away for the browser client to detect this type of hole and alert end users to the risk...
No, it's fundamentally impossible - as far as the browser is concerned it's talking to a server that's speaking HTTPS (CloudFlare's server) and it can't possibly know what that server's doing behind the scenes.
If I see HTTPS in the title bar I expect the owner of that certificate to be responsible for the content I'm seeing. It's utterly irresponsible of CloudFlare to enable this kind of configuration.
Can you pass down a header to the client describing the security of the origin connection? Or let me pass CloudFlare a header that I explicitly would rather you drop the connection than plain text it back to origin?
I like the idea of a client-specified HSTS header - allowing users to control their risk directly (albeit through a browser extension) would definitely be a good thing.
The threat is completely different, although I agree with you they're providing the illusion of end to end security when that's not the case.
The likelihood of a bad actor between Cloudflare and the origin server seems lower than a bad actor between Cloudflare and the user - where I'd class a coffee shop wifi portal page as a bad actor.
... and I'm pretty sure that their response will be "We are just a proxy, we are not responsible for anything".