HTTPS Everywhere, and Beyond

Last updated December, 2016
tags: https everywhere, tls, encryption, web
 
 

HTTPS everywhere is an exciting and important event in online security from the EFF to help users everywhere default to secure connections. It also foreshadows a larger current to move much of the web towards encrypted-by-default behaviour over the coming years.

Let's take a quick look at the sticks and carrots being used by the major web browsers to hurry us along.

Background

"Wait, what?" some of you are surely asking. Yes, it's true, all of those security warnings you've been ignoring for years about side-channel attacks and SSL3 vulnerabilities were actual real things that required your attention as someone who exists online. If you happen to make your living here this part is extremely important: the world is moving to HTTPS-only. It may take a few years, but that's the way forward.

Between clever hackers stealing endless amount of bitcoin, major retailers loosing databases of credit card numbers, a botched Turkish coup, Western hackers selling tools to global despots, and the ever growing lidless-eye surveillance powers of governments, there has never been more reason to beef up global internet security, especially for those few in the game of providing the main portals between the internet and the world—browsers.

Browsers are trying in various ways to coax the wider web to adopt better security practices, both with incentives and warnings.

Carrots

SEO

Obviously Google controls more than just the Chrome browser. The real carrot from Google is their promise that canonically HTTPS sites will receive a boost in their SEO ranking. Provided your Google-game doesn't rely on paid user acquisition alone, an SEO boost is a pretty juicy carrot. But how big is it? At launch in 2014, Google claimed only a 1% effect on signal, but promised an increasing influence over time.

Google's Lighthouse performance auditing tool also includes HTTPS Everywhere validation (since it is required for nearly half of the other features it tests on). Though this doesn't factor into SEO as yet, it is certainly a leading indicator of where things are heading.

Sadly, it doesn't look like Google is pressing the gas very hard on this one at the moment in direct search results, but we can expect that over time it will become an increasingly hard to ignore factor, especially with UI "incentives" listed below.

UI Trust Features

Everyone like green, at least when it comes to traffic lights and dashboards. They like it much more than red. Through years of training we've all become accustomed to the association that green is good, and red it bad. Very bad. The UX folk might even go so far as to say that green "delights" users, and red... well, I don't know, "pain" them?

With all of this in mind, I invite you to look up at your navigation bar in all of it's discretely-green glory. That means you're safe. You're protected. To the user who knows nothing of cryptography and is blissful in this ignorance, it is the simple difference between "Ah, now I know I am safe" and "Oh, hm, I wonder if hackers could get me?". Most major browsers include this, even on mobile—though sometimes only in the form of the minimal and tasteful lock.

If you want it, either to engender trust or competence, you'll have to be on HTTPS.

The Modern Web

Much of modern web development is being made available for HTTPS-only. Here are a few that are probably relevant to most of us:

Accelerated Mobile Pages and Progressive Web Apps

PWAs are an emerging standard Google is pushing to achieve app-like performance and features on mobile web, and AMP is an effort to get the beach-head of a site loaded as quickly as possible. The two can be thought to work hand-in-hand as they achieve slightly different results. Strictly speaking, AMP does not require HTTPS, but to get it to lay the ground work for a PWA, you're going to need HTTPS. You see, PWAs are really a loose federation of technologies that deliver this amazing new experience, and a key bit of that magic is Service Workers.

Service Workers

"Any application that can be written in JavaScript, will eventually be written in JavaScript" -Atwood's Law

Ever the prophet, Jeff Atwood seems to have predicted that somehow JavaScript programmers would want to nuzzle in between the browser and the network. After much consideration, the browsers have managed to make this possible. Of course, granting sites the ability to intercept and rewrite network requests is an incredible amount of power, and to dole it out responsibly meant that they needed to ensure the authenticity of the service worker payload. Any guesses on how we do that? Some kind of protocol that includes both source authentication and payload validation? Some way of transporting a file securely over the network layer?

Anyway, not to belabor the point, but if you want to make use of these incredibly powerful features, you need to switch to an HTTPS site—though if you're very clever you can just use an HTTPS iframe... but don't, because it will complicate your life and your future-self will curse you. If you want to be riding the wave of modern web development you need to be HTTPS.

HTTP2

There are a few competing ways of pronouncing this one, but I'm really pushing for "H2" to save millions of developer-hours sounding out all the letters.

A few notes, this shiny new HTTP version only works over HTTPS... so you know... there's that. Most of the protocol is geared towards speed ups, including server-side-push (where you know that the client is going to request X so you send it down along with the initial reply), and delta-based session headers (where you only have to retransmit a header if something has changed).

Also, the protocol has abandoned the plaintext HTTP exchange for an encoded schema to save space, which is sad but understandable—no more plaintext packet sniffing, which is less useful over HTTPS anyway.

All of this is to say that the HTTP2 protocol is here to offset whatever argument you're used to about HTTPS being slow. All of these speedups should more than offset the TLS handshake.

Sticks

SEO, Again

It should go without saying, but if your HTTPS competition is getting an SEO boost, you are effectively getting the inverse without it. The top 10 page is a zero-sum game.

Within very short order, SEO best-practices will dictate HTTPS is required, and will thus align marketing and infoSec/devOps interests.

Shaming UI

Remember how green is good and red is bad? Starting January 2017 Chrome will begin not only displaying green on HTTPS sites, but marking certain HTTP sites as red. Firefox already has a similar feature in the pipe.

This is important for several reasons: The red mark used to be reserved for broken HTTPS setups, which is bad of course, but means that it's associated in user's experiences not with non-secure sites, but insecure sites. An important technical difference, but perhaps too subtle in the learned responses of users.

If your site has a login form or credit card form, and isn't served over HTTPS, Chrome and Firefox are going to start marking it red.

This seems like a reasonable step, but keep in mind it's only a first step. The stated goal of the Chrome security team is to eventually mark all HTTP connections as non-secure.

Vendor Progress

Evergreen browsers mean that vendors now have the ability to push an HTTPS world out at their own pace, only waiting for a large enough web base to make it justifiable. This is a meaningful change from the time of endless Windows XP and IE6 support, and keeps the world moving forward at a faster pace.

Google

Both as the primary SEO Dictator and the primary browser vendor, Google is well positioned to push it's agenda, and it's agenda is HTTPS. Exhibit A: "...as part of a long-term plan to mark all HTTP sites as non-secure." As mentioned, Google will be issuing warnings on any site with a password or credit-card field that isn't HTTPS starting January, 2017. Google is also the primary advocate behind much modern web protocol changes, and couches much of it in an "only available over HTTPS" shroud.

Plus, you know, over half of web users are using a Chrome variant.

Apple

Apple has made the HTTPS-everywhere push most strongly in the Apps development scene, starting with iOS9. There's been little word on the browser-front however, and it's unlikely that we'll see the Safari team be as push as Chrome in their security stance. That being said, although Safari users are considered "high value" from an ecommerce perspective, they're really very much in the minority.

What about mobile?

Given the limited UI possible on mobile there are two ways a mobile browser can go. Uncluttered with minimal alerting, and highly intrusive alerting that a user can't fail to notice. Mobile Chrome has already demonstrated a willingness to alert users and is expected to be as visible about HTTPS status on mobile as on desktop (in fact the effect may be amplified, given the smaller available pixel count). Safari has long given users pop-up warnings for expired certs, but insists on displaying a stylized black lock even on invalid sites. This doesn't leave much hope for them getting more aggressive with their warnings.

Mozilla

Mozilla appears to be of a mind with Google on the spirit of forcing everything to adopt HTTPS communication by default. Mozilla has also backed a number of initiatives to make this easier, including Let's Encrypt. Between Mozilla and Chrome, two-thirds of web users will be on browsers aggressively pushing HTTPS.

But, but, but...

Every conversation I've had with an established IT team around rolling out HTTPS-only for a legacy project usually hits a handful of the same objections, so lets address some of them here.

Certificates are expensive. Well, yes and no. Some certificates can cost upwards of a thousand dollars per annum, but they really don't have to. In fact, there are lots of ways to grab free TLS certificates these days, either directly from your platform provider, or through a program like Let's Encrypt.

Encryption is too slow. The addition of a TLS handshake will add two round trips immediately after the TCP handshake completes. New features in TLS3.0 (expected to roll out in the summer of 2017), and available for some now in the form of TLS False Start and TLS Fast Open can get this back down to one or one and half round trips. In short, it's not that bad, and it's getting better.

HTTPS is hard to do correctly. That's not really true anymore; there are great resources online (including here) to help you get oriented. The good news is that the default safe settings are winnowing down and are easier than ever to get correct. Also, HTTPS-only means that a whole class of tricky vulnerabilities go out the window. If anything, you simplify your perimeter by moving everything to TLS.

But I don't need security. Maybe?

Maybe your site is statically generated and serves nothing but uncompromising kitten pictures and could never be used for malicious purposes.

Or, maybe you're just running a WordPress cookie blog... oops, nope, then you still want HTTPS-only... you have that admin page after all.

Maybe you're an online tech magazine who should know better and you want everyone to be reading everything, even over HTTP... but you still have an account login button! While that doesn't mean you have an active exploit, it does mean you are more likely to be vulnerable to certain kinds of attacks. Also, Chrome might start shaming you soon, and you wouldn't want that.

Parting Thoughts

A fully encrypted web is very good news for the web as a whole, and is something we should all be celebrating. If you need any help justifying the move to your boss, please let us know, either through email or twitter. If you win, we all win.

 
 

Want more?

Subscribe to get new resources like this one, and to be notified of updates.

Subscribed! An email confirmation has been sent.