CloudFlare have recently announced two great new features in the form of Keyless SSL and Universal SSL. Despite the fact that Keyless SSL addresses some of the concerns I outlined in my previous blog post, I still can't bring myself to switch back.
Keyless SSL
Keyless SSL allows a host to get around the issue of having to turn over their private key for CloudFlare to act as a reverse proxy for their site. Previously, you either had to hand over the key, for CloudFlare to act as an intermediary, or CloudFlare would present one of their own certificates to the browser and not the certificate of the host. These 2 options both seemed to breach the trust mechanism of SSL in some way. You either have to give your private key to a 3rd party, or have your site presented to the end user with someone else's certificate backing it up. Keyless SSL changed that.
images source CloudFlare
By running a specialised key server on your own premises, CloudFlare can still perform a majority of the SSL handshake process but pass back the 1 part that requires the private key. In an RSA handshake that's the decryption of the Pre-Master Secrect sent by the client, and in an EC/DHE handshake, it's computing the signature of messages exchanged up to that point. This means that the private key stays in your hands and under your control at all times.
Universal SSL
Universal SSL is the second new feature announced by CloudFlare that allows any customer, even those on free accounts, to have SSL for their site.
image source CloudFlare
Anyone sat behind CloudFlare can now enable SSL support for their site. That means, at a minimum, that the connection between the browsers and the CloudFlare edge node will be encrypted. This is where my problem starts to creep in.
Why do they offer Flexible SSL?
There is quite clearly some fantastic work taking place over at CloudFlare, but I just can't get around Flexible SSL. For those who haven't read my previous blog, Flexible SSL is where a host uses SSL between the browser and CloudFlare but not from CloudFlare to their origin server. This means that the users sees all of the indicators of SSL, a padlock in the browser and https in the address, but their traffic is still traversing a majority of the route in plain text. Of course, there are the options of encrypting the back end, but they're just that, options.
Nick Sullivan, Security Engineer at CloudFlare, did make some interesting points regarding this.
@rambling_rant @ivanristic @cloudflare Most threats http are from local networks and ISP. This blocks them. http://t.co/bzrlYSIuZQ
— Nick Sullivan (@grittygrease) September 29, 2014@rambling_rant @ivanristic @cloudflare We strongly suggest that people use Strict mode with a valid cert on their origin.
— Nick Sullivan (@grittygrease) September 29, 2014The benefits
It is true that a user does face a large number of threats on their end. All of my blog posts on the WiFi Pineapple show just how many threats a user can face and that's before the data has even left the premises. You then have your own ISP and anyone else that can get their hands on the data before it winds up at your local CloudFlare edge node. By using Flexible SSL all of these risks can be mitigated. The problem is, should a less responsible host, let's say, accept credit card data, the user sees all the trademarks of a secure site and inserts their data, but it's still going to be zipping across the wire in plain text for a majority of the journey. I'm aware that this is an age old problem of SSL termination in that we, as users, don't have any idea where a host terminates their SSL and where the data goes after that. This isn't a new problem that CloudFlare have introduced, this is an old problem that they've brought a lot of attention to.
The drawbacks
Do we give the user all the indications of a secure transport layer when it's not secured end to end or should we show http at the front and let them know there's a risk? Are browsers to blame for giving indications that communications are secure when they don't know where SSL is terminated? These are the kind of questions crop up when I think about it. Typically, if a host terminates SSL it will be close to the end of the line, right at the edge of their own network. When CloudFlare terminates SSL, it happens as close to the user as is possible, such is the purpose of their network. This means that pretty much the largest possible amount of the transport layer isn't protected. That said, have we encrypted the part of the transport layer that presents the greatest risk? Is that enough to still give all the indications in the browser?
Do we give an illusion of more security than there is whilst mitigating some risk or stick with no security and have the user know all the facts?
Ivan Ristic, the guy beind the Qualys SSL Test, put it quite nicely.
@grittygrease @rambling_rant @cloudflare It would be interesting if you would indicate if there’s no origin encryption.
— Ivan Ristic (@ivanristic) September 29, 2014@grittygrease @rambling_rant @cloudflare @jgrahamc Yes!
— Ivan Ristic (@ivanristic) September 29, 2014A host might try to hide the fact that they don't have encryption on the origin side of their connection, but the response from Nick Sullivan is quite promising if it comes to pass. CloudFlare don't want them to be able to hide that fact it seems. Ok, it's not exactly ideal, in that everyone would need to Qualys Test any site they use, but I imagine it could also be added as a feature to the CloudFlare Claire Chrome Extension too. All that said and done though and we still have the same issue in the browser. It looks like we have an entirely secure transport layer when we don't.
SSL all the things
CloudFlare do, of course, offer the ability to encrypt the back end of the transport layer too, from CloudFlare to the origin server. This is known as Full SSL and Full SSL (Strict) in the CloudFlare control panel. Full SSL means you can use any old self signed cert on the origin and CloudFlare will accept it. This protects against passive snooping but an active attacker can step right in there and switch it out as CloudFlare don't currently have the option to pin the cert. Full SSL (Strict) seems to be the only way to go for me and requires a CA issued certificate on the origin server that CloudFlare can verify.
image source CloudFlare
Once they have the option to pin certificates, it seems CloudFlare could become a sort of CA and issue certs to their customers to use on the back end. This removes the need to purchase a cert from a formal CA and still maintains all the security required on the transport layer.
The changing landscape of the Internet
It's difficult to look at all the great features CloudFlare offer and not want to use them. They employ some incredibly smart people and here I find myself wondering why they do some of the things they do. Traditionally, a website would have been a single server in a rack somewhere with all the data it required stored right there, including the SSL private key. As the Internet has exploded into the global phenomenom it is today, the architecture of the Internet has undergone some radical changes.
The era of cloud computing has completely changed how we operate a website. This blog isn't hosted on hardware I own or even manage, it's a virtual container alongside many thousands of others hosted on DigitalOcean. They have access to all of my traffic and my private key, much like Amazon or any other cloud hosting provider would. Is bringing this 3rd party into my circle of trust any different to bringing in someone like CloudFlare?
The whole concept of SSL termination has gone from something that only happened in big projects at the edge of your private network to something that can happen on a global scale at the click of a few buttons (literally). When we see a valid certificate in use on a website, does that mean that we are talking to the host and only the host? Do users expect other 3rd parties to be involved in the custody of their data? These may be the changes that we have to come to accept with the modern web and how it works.
Keyless SSL would be a big draw for me to use CloudFlare again if it were available to me, but for the time being, I'm just not sold on the option of a partially secured transport layer being available. If we were to find out that Google or Amazon were terminating SSL at some arbitrary edge node and then sending our data across a majority of the journey on public networks in plain text, there would be uproar. Hosts need to be responsible and ensure that if they are using encryption, that at any point our data is on a public network, it is encrypted. The temptation is there for too many to act in an irresponsible way and CloudFlare seem to be supporting that behaviour.