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.
bob
Isn’t it nice that the 2 biggest marketing companies in the world will keep this giant databse of HSTS sites just for your convenience. A cyncical person might think something fishy data gathering was going on there.
Paul Ducklin
HSTS data isn’t meant to be secret. It’s meant to be as widely known as possible, precisely to avoid the need to connect via HTTP to find out that HTTPS was there all along. In short: HSTS is a kind of “real time” way of rewriting old HTTP links into HTTPS ones, at the cost of an insecure connection to find out about the secure one that’s now preferred.
Given that Facebook and Google can collect (and are collecting) this data anyway, surely it’s better that they actively use it “for your convenience” (as you say), not merely for their own?