The web is going HTTPS only. In theory.
The idea is that unless we encrypt all the transport things, we can have no confidence in the confidentiality, integrity or authenticity of the traffic and services we’re talking to. There’s growing awareness of how essential secure transport comms are (thank you NSA for your part in helping us come to this realisation), and indeed we’re being continually pushed in this direction. For example, last year Google said they’d start using the presence of HTTPS as an SEO ranking signal. They’re also recommending that browsers begin changing their UX to display non-secure origins as affirmatively non-secure or in other words, flipping from the model from displaying nothing about the connection security when the resource is HTTP to instead explicitly saying it’s an insecure connection. This is all very good and it’s moving us in the right direction. Except there’s one big problem…
Yesterday Scott Helme posted some stats on the results of him crawling the top 1M sites based on Alexa rankings. He was looking for response headers such as HSTS, HPKP and CSP, but he also took note of how many sites were enforcing HTTPS by redirecting any HTTP requests to it. The result? Less than 7% of the top 1M sites are doing HTTPS only. I can only assume it drops off as you go further down the order too as clearly those top 1M include a disproportionately large number of banks and other assets which are more predispositioned to being secure by default. So why is this?
SSL is still a premium service. It’s either harder to get than just plain old HTTP services, more expensive or in some cases, just impossible. Let me give you some notable examples that I’ve come across in recent times because despite my best efforts, I continually face both financial and technical hurdles.
Blogger
First off, unless you’re reading this in the future, you’re reading it on my blog over an insecure connection. That wasn’t such a big deal in 2009 when I started it, but it is now and there’s nothing I can do about it without investing some serious effort and dollars. I run on Google’s Blogger service which ironically given their earlier mentioned push to SSL, does not support it. Whilst Google doesn’t give me a means of directly serving content over SSL, I could always follow my own advice and wrap CloudFlare’s free service around it, but that won’t work unless I update the source of every single image I’ve ever added to almost 400 existing blog posts… and there’s no find and replace feature. This is the joy of SaaS – it’s super easy to manage and good at what it’s specifically designed to do, but try and step outside of that and, well, you’re screwed. Unless…
Hey @CloudFlare, how about a feature to rewrite embedded content to use the HTTPS scheme? Make it easy to drop SSL on without mixed content.
— Troy Hunt (@troyhunt) August 10, 2015
One minute later I had a response from CloudFlare’s CEO (kudos to him!):
@troyhunt we're thinking about how to do that. We want to make sure it works with even content loaded by JS onto a page (e.g. ad nets).
— Matthew Prince (@eastdakota) August 10, 2015 Fair enough, it’s not an easy problem to solve, but there’s an opportunity for them to tap a market of people in precisely my predicament if they can get it right. Without the service (i.e. Blogger) natively supporting HTTPS and without a low-friction way of wrapping SSL around it, everything gets harder. Not just harder, but more expensive; Blogger is 100% free, even on the occasions where I’ve had hundreds of thousands of page views in a day and that’s the sort of volume which can cost some cash with commercial services.
The bottom line is that I get put in this predicament: in order to support SSL on a 100% public blog site that doesn’t collect any information from anyone or represent things where integrity and authenticity are vital and likely to be at risk of an MitM attack, I must invest days of effort and pay money on an ongoing basis as well. You see how it’s difficult to justify the ROI? I want to do it and if it was easy and cheap or offered a tangible upside then I would do it, but unfortunately it’s none of those things so it’s not on the immediate term set of priorities.
It will, however, eventually happen so perhaps I should just move to another blogging platform and just fix the image sources myself? For example, I recently created Kylie’s blog on hosted Ghost which is excellent. But ignoring for a moment the effort involved in moving the entire blog contents, template and all the other necessities that go with it, Ghost has their own problems.
Ghost Pro
I put Kylie’s blog on Ghost Pro which is effectively their hosted platform. Unfortunately though, when it comes to SSL there are a couple of problems with their pricing plan:
The first problem is that there is no SSL. Yes, it’s “coming soon” and that’s great but this alone gives you a sense of how high a priority it is. Now I don’t just want to pick on Ghost because they’ve been excellent and this is more reflective as the industry as a whole, but it was obviously more important for them to get a service out there with no transport layer protection than it was to properly secure it.
The other issue is the cost – it’ll triple in order to support SSL. Kylie is running on the $8/m plan which is just right for a brand new site, but she’ll have to go $24/m in order to support SSL. This is what I mean in the title about SSL being a “premium service”. Philosophically it should be a foundational component of every website but whilst services market it as a commercial offering, it will continue to be ignored by many sites.
If you followed the link through to Kylie’s site, you may have noticed it’s actually https://kyliehunt.com because I’ve wrapped CloudFlare around it. Unfortunately though I can’t redirect all requests to the insecure scheme over to HTTPS. Why not? Because of this:
<meta property="og:url" content="http://kyliehunt.com/"/>
The Open Graph tag that Ghost adds to the source of their SaaS offering explicitly uses the HTTP scheme. If you’re 301’ing back to the secure scheme then as soon as you try and post an HTTPS link to Facebook and it goes and crawls the site, it finds the og:url tag and requests the URL in that instead because it’s using a different scheme. That then results in a 301 to the secure scheme which returns the tag above again with the insecure scheme and, well, things go in circles until it gives up. And you cannot change this on their SaaS platform.
Ok, so maybe I should just host her blog directly on Azure instead and manage it in a PaaS style with their website offering? There are logistical reasons why I don’t really want to do this (mostly boiling down to me not wanting to now maintain a blogging platform), but let’s go and take a look at the Azure offering anyway.
Azure
Here’s the Azure website service tiers:
The “Shared” model is an excellent resource for standing up a small website on a custom domain and it’s less than $10/m. Unfortunately though as you can see from the chart above, there’s no option for SSL so you have to move to the “Basic” offering. Now we’re looking at $56/m for that plus another $9/m for SSL which is almost seven times more expensive. Now you do get a lot of extra stuff with this service tier and as you may already know, I’m very supportive of the Azure platform as a whole but this just goes to support my premise for writing this post: SSL is a service that you frequently pay a premium for and as a result it is detrimental to the uptake of secure communications on the web.
More and more of the same
These are but a few examples that have directly impacted me in recent times, but the list goes on and on beyond those.
Hosted WordPress on WP Engine charges you $50/y for a cert and won’t let you bring your own on their entry level plan:
If you want to host Drupal on Rackspace then that’ll be another $20/m:
Even the marketing around SSL is a mess and I recently lamented how Comodo were presenting non-EV certs in an unfavourable light:
Holy crap, I never knew how sad people look when they're browsing a site without an EV cert! https://t.co/SHKJzV6IPm pic.twitter.com/OInFWf8YTo
— Troy Hunt (@troyhunt) August 5, 2015
This is just ludicrous! It inevitably lead people to ask – “Is the encryption of an extended validation certificate really that much better?” – of course it’s not! It only adds to the confusion and complications that surround SSL.
Can we all just get on with making this happen properly already?!
As soon as someone is faced with the option of doing something cheaply and easily versus with more money and more effort, the former is going to be the default position unless they can readily justify the friction of the latter and that’s where SSL frequently is at the moment. CloudFlare is the notable exception here and kudos to them for helping fill the present gap by giving everyone SSL for free (even if it’s just from the browser to CloudFlare’s infrastructure) and allowing them to wrap it around their existing service but even that requires people to actively seek it out and configure it.
The barriers above aren’t too much of a hurdle for sites of a scale and significance that benefit the most from SSL, they’ll jump through the necessary hoops required to get it. The real problem is the very long tail of smaller sites that don’t have an explicit requirement to serve traffic securely and in lieu of not having an option to do so, simply don’t. Like troyhunt.com, they then become more and more tied to insecure comms and the barrier to change at a later date gets higher and higher.
The Let’s Encrypt initiative has a lot of promise but who knows when that will actually launch let alone be seamlessly integrated into the services mentioned above. I’ve been watching their homepage eagerly this year and paying particular attention to the launch date:
Even when it hits, will the likes of Google, Microsoft, Ghost et al embrace the “free, automated, and open” nature of it and cannibalise revenue from both the direct SSL services they sell and the up-sell it forms as part of in their higher tier offering? It’s unlikely and unfortunately that means that for the foreseeable future, SSL will remain as a premium service and customers will overlook the benefits in favour of immediate term cost. Until there’s an “Add SSL for free” button, this whole thing is going to continue progressing at a very, very slow rate.