HSTS is the great little response header that tells a browser to always use SSL/TLS to communicate with your site. It doesn't matter if the user, or a link they are clicking, specifies HTTP, HSTS will remove the ability for a compatible browser to use HTTP and will enforce the use of HTTPS. This still leaves a user vulnerable on their very first connection to a site though. HSTS preloading fixes that.
HSTS
My previous blog on HSTS goes into detail on all aspects of the HSTS response header, you should probably read that first if you haven't already. If a site uses SSL/TLS, and redirects traffic from HTTP to HTTPS using a 301/302, then their implementation can't be complete without issuing the HSTS response header. This protects the user in every circumstance apart from their very first visit to the site.
What is HSTS Preloading
HSTS Preloading is a mechanism whereby a list of hosts that wish to enforce the use of SSL/TLS on their site is built into a browser. This list is compiled by Google and is utilised by Chrome, Firefox and Safari. These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is already aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP. This isn't to say that the host needs to stop issuing the HSTS response header, this must be left in place for those browsers that don't use preloaded HSTS lists.
Signing up
Adam Langley runs a website here where you can sign up to have your domain name included in the HSTS preload list. To ensure that domains aren't submitted without the owners consent, you have to modify the HSTS response header on your server to indicate that you wish to be preloaded.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
By adding the preload token to your response header, the guys at Google can be sure that you want to be included in the list. The preload token is no longer present in the header for my site as I have already been accepted onto the preload list. Once you have submitted your site, you can enter your domain again to check the status of your application, and once completed, you should see something like this:
Things to note:
If you enforce SSL/TLS sitewide you should issue a HSTS response header and submit your site to the preload list.
If a site you use doesn't issue a HSTS response header, you can manually enforce HSTS in Chrome using my previous blog. That way, Chrome will always use HTTPS no matter what.
But it doesn't scale
Whilst there is the potential for these lists to scale to huge numbers without being too much of a burden to download, it's not really a future proof solution. Not to mention that managing domains on the list could be problematic when inevitably somebody wants a domain removing. We need to know that a site wants us to use HTTPS before we make an initial connection over HTTP. We could use a DNS record to deliver our HSTS policy but then we're back to the problem of plain text comms so need to use DNSSEC. Maybe browsers shouldn't default to HTTP as their initial choice and instead try HTTPS and fall back to HTTP? The worry here is the poor user experience while that happens, but it'd only be the first time you attempt to connect. It's an interesting problem, let me know your thoughts in the comments below.
Update 10th Jun 2016
The HSTS preload submission site has had several updates. You can now check the status of a domain and the eligibility for preloading without submitting.
There are also 2 new API endpoints that you can use to check the current preload status and whether a domain has any errors or warnings that would prevent preloading!
https://hstspreload.appspot.com/api/v2/status?domain=scotthelme.co.uk
https://hstspreload.appspot.com/api/v2/preloadable?domain=scotthelme.co.uk