The campaign to make HTTPS universal scored a huge win this week with the news that Facebook has started upgrading external links to use HTTPS when sites support it.
In other words, if a user puts a link into a Facebook post that starts with http:// but the site they’re linking to appears on an HSTS preload list it’ll be written to https://.
If this sounds incremental, it’s anything but: links clicked on from inside Facebook and Instagram have grown into one of the most important ways many internet users discover websites, so anything that boosts security here will have a big influence.
The announcement might seem simple but something quite extraordinary is going on when you stand back a bit.
Facebook’s Data Privacy engineer, Jon Millican:
This will improve people’s security and will also often improve the speed of navigation to sites from Facebook.
To understand why, it’s necessary to understand why HSTS is a good idea and how preloading improves matters.
The TL;DR is that HSTS is a way for a website and a browser to co-operate to ensure everyone visiting it does so over secure HTTPS (SSL/TLS) rather than insecure HTTP.
In other words, just having an HTTPS server isn’t enough – the site has to make browsers use it, communicated by sending the browser an HSTS response header when it first connects, after which HTTP is no longer an option.
This stops users from connecting to insecure HTTP manually or through a downgrade attack.
The obvious flaw is that the first time the user connects to the site (before they receive the response header policy), they are briefly vulnerable to a downgrade attack that keeps them on HTTP and routes them through a man-in-the-middle who can snoop on or modify their traffic.
Preloading solves this with a global list of websites (maintained by Google’s Chromium team but available to other browsers) and their HSTS policies. As long as the browser keeps this up-to-date, it won’t make those initial, insecure requests to any of the sites on the list.
But there’s another problem:
Despite many modern browsers supporting HSTS, some people still use browsers that don’t support it.
Presumably, this is a reference to Internet Explorer before v11, or old versions of Android on phones that can’t be upgraded.
Normally, there would be no way around this limitation, but Facebook has decided to step in by becoming, in effect, a sort of gigantic HSTS resolver.
This requires Facebook to pay attention to the Chromium preload list. In addition:
We record HSTS headers from sites that are shared on Facebook. We supplement the browser preload list with any sites which serve HSTS with the preload directive.
It’s reminiscent of Google’s announcement in October that it planned to implement HSTS preload on Top-Level Domains (TLDs), applied to every HSTS-compliant website pointed at from within the Facebook empire.
With Google also herding site publishers to use HTTPS, and Facebook prioritising HSTS, it’s like a giant pincer movement designed to communicate a simple fact: at some point, sites not using HTTPS will start to find their traffic drying up.