Adapting Your OS X Server Strategy for SHA-1, SHA-2, and HTTPS Everywhere

Whoops, Google has decided your site will be at a disadvantage without HTTPS support. Whoops, Google has decided you’ll need to replace that shiny new server certificate you just bought. This is the first in a series of three articles exploring how to adapt.

Google Makes the Rules

Less than a month after Google’s August 2014 announcement that a site’s use of HTTPS would be considered as a ranking signal, everyone’s favourite web dictator threw the world a curveball with the unexpected announcement of an accelerated sunsetting of the SHA-1 hash algorithm. Although a gradual phasing out of SHA-1 in favour of stronger algorithms had been on the radar for a long time, and a timetable had already essentially been set by Microsoft some time ago, Google’s abrupt acceleration of the process means that starting with Chrome 40 (branch point 7 November 2014), sites with certificates expiring between 1 June 2016 and 31 December 2016 and which include a SHA-1 signature anywhere in the certificate chain will be given the Chrome yellow card and treated as “secure, but with minor errors”. Even sooner, starting with Chrome 39, the same applies to certificates expiring after 1 January 2017. And as of Chrome 41, expiries during the whole of 2016 will be shown with the yellow card, while those expiring in 2017 and onward will be shown as entirely insecure.

In a nutshell, if you’ve purchased a certificate during 2014, with anything other than a 1-year expiry, and you chose SHA-1 with an awareness of the industry’s existing timetable for sunsetting SHA-1, you’ve now been given a matter of mere months before your users will be handed a strong visual cue that something is wrong with your site.

Certificate authorities (CAs) are not happy about Google’s decision to provide so little warning and their apparent failure even to consult with CAs on the timetable prior to the announcement. In private conversations, some would probably best be described as apoplectic. (While Google later backed off a little from their initial aggressive plans, it doesn’t seem to have done much to smooth the ripples of ruffled fur across the industry.)

Many webmasters are not happy either, and those who immediately jumped through hoops to add TLS support to their sites after Google’s first announcement and their brazen co-opting of the term “HTTPS Everywhere” (which originated with the EFF and Tor), and who chose SHA-1 certificates, are least happy of all.

Why Support SHA-1 at All?

There are actually very good reasons why many webmasters would have deliberately chosen SHA-1 certificates. First among those is the fact that any version of Windows prior to XP Service Pack 3 cannot use SHA-2 certificates — regardless of browser or browser version. Laugh at XP if you will, but not only do pre-SP2 machines exist in large numbers across China, for many sites, a large chunk of their most valuable visitors are still using XP, such as those which cater for medical professionals using legacy systems in hospitals and research facilities.

Between the loss of support for legacy browsers and the massive costs associated with rolling out new certificates, it’s easy to see why most of the world that is non-Google would have appreciated a little more than a few months notice to adapt to the situation.

Should You Bother With TLS/HTTPS at All?

Stepping back from the details of algorithms and timelines and operating system support, what about the question of whether to support HTTPS connections at all?

I’m all for increasing security and privacy and for reducing or eliminating unwarranted (and warrantless) nosiness about the activities of web users. But adding HTTPS to a site is not by any means a no-brainer, even for those of us who are strongly pro-privacy and even given Google’s decision to count it as a ranking factor. It would still not be a no-brainer even if all browsers under the sun could be counted on to grok whatever hash algorithm was flavour of the day. Why?

Adding HTTPS support is still not a no-brainer because, contrary to what seems to have become Google’s favourite set of facts-turned-propaganda, TLS connections as of this writing necessarily introduce latencies for web users. Currently, communicating over HTTPS requires the browser to communicate with the server to set up the encrypted connection first, before handling any other business. That takes time and at least one round trip from browser to server and back again. Regardless of how much business then gets conducted through a given encrypted connection — even if that means all of it, in the case of Google’s favoured solution, SPDY — setting up that connection still takes time. Multiply that additional time for every new connection that must be opened to other servers in the course of building a page (except for those that might happen in parallel, which can never be all of them), and the additional latency for your users may grow to several hundred milliseconds. In some cases, it may be counted in full seconds.

Yes, I get the propaganda: obviously all this can be optimised, and obviously TLS connections can be made pretty darned speedy. But pretending that adding HTTPS support won’t slow down a site on the grounds that TLS can be optimised is a bit like pretending that adding more images or JavaScript libraries to a web page won’t slow it down because well, you know, we can compress images and JavaScript. Give me a break.

So, one major question about adding HTTPS “everywhere” revolves around just how much delay you’re willing to foist on your users. As I said above, I’m all for increasing security and privacy. But I also understand the reality that many web users, when given a choice, will reject secure but slower browsing in favour of insecure but faster browsing. HTTPS support may be a ranking signal, but so is overall page load time — and for good reason. Every webmaster who cares about performance and speed will have to evaluate this balancing act between privacy/security and speed for themselves.

For site owners and server administrators who do decide to take the plunge, there are plenty of implementational details to get right, and there are many optimisations to consider — but I’ll turn first to the question of how to provide both SHA-1 and SHA-2 support in the next article. See “How to Deliver Both SHA-1 and SHA-2 Certificates With Your OS X Server”.

• HTTPS everywhere
• macOS
• security