The Background

When Internet was first designed, security was not the the primary focus. With dedicated connections between nodes, limited access and CPU power, encryption did not seemed so necessary at the beginning.

However, as the scale of Internet continues to grow, and the growing popularity of over-the-air connection media (e.g. Wifi), encryption is almost a must feature for responsible websites. Unfortunately, it is easier said than done, especially trying to done it correctly.

Forcing TLS Connection

Nowadays, to force browsers to use TLS connection while connecting to a website, one can set a simple 301 redirect to redirect from non TLS URL to TLS-protected URL. Like this:

GET / HTTP 1.1/
Host: www.idndx.com

HTTP 1.1 301 Moved Permanently
Location: https://www.idndx.com/

However, this approach has a significant flaw. Notice that the initial HTTP transaction that triggered the redirection was sent over non-secure channel. An attacker with ability to control the connection between the client and the server could easily strip the 301 redirection returned by the server and act as MITM proxy easily.

Users' Decisions

One thing I have learned these years is that ordinary user does not care or understood the implication of a non-HTTPS URL or perhaps a red screen warning an untrusted certificate. For most user, the desire to access the website and get their job done tends to make them ignore the secureness of the connection between their client and the server.

Or, guess how many user will just happily tap the "Continue" button, especially when Apple decided to bold it?

HSTS To The Rescue

HSTS, which stands for HTTP Strict Transport Security, is by no means a new technology. If enabled, the web server will send a special HTTP header in every response denoting to the client that this domain should only be accessed through secure connection. Specifically:

• Within the specified time, the client should never access the site through non-secure connection. That means the client should not attempt to exchange any information with the server unless the connection is secure.
• Within the specified time, the client will enforce strict certificate validation on all secure connections it makes with the server. Expired, non-trusted or otherwise problematic certificate or handshake will result a permanent failure on the client side. The user would not have the option to skip those checks.

HSTS does have an expiration time that the server could set to indicate how long those strict check requirements should be cached inside the client. However, we still could not solve the problem of a possible MITM before we even got the chance to send the HSTS header to the client, as mentioned previously.

In order to solve those problems, the Chromium Project came up with the idea of "HSTS Preloading". Maintaining a list of domains that will be distributed with browser installations thus even without any cached HSTS information, a MITM attack won't be possible since the browser will knew the HSTS requirements before even establishing connections with the website the first time.

How To Do It?

The participation of HSTS preload is completely voluntary and has to be explicitly requested by the site administrator. In short, here is what you need to do in order to add your domain to the list:

1. Go to https://hstspreload.appspot.com/. Read the requirements and make sure your server complies to those requirements.
2. Submit your domain, wait for approval.
3. Once approved, your domain will appear in transport_security_state_static.json, and will be distributed through the next Chrome update.

My Experience

I submitted my domain idndx.com to the HSTS preload list a while ago and it got added to transport_security_state_static.json just after about a month of review period. And it feels good to know that my visitors are protected through this simple action on my side.