HSTS is one of the most important aspects of HTTPS performance and security optimization, and can bring huge benefits to HTTPS, but there is a small downside. This article explains how HSTS works and how you can use the HSTS Preload List to solve HSTS minor defects.

What are HSTS?

HSTS stands for HTTP Strict Transport Security, that is, HTTP Strict Transport Security. Before introducing HSTS, let’s take a look at the most typical user access to HTTPS: When you visit a web site, you simply enter the site address in the browser, not the protocol name. For example, to visit the official website of Dingo, we most often use www.wilddog.com, even though the website is full site HTTPS, we rarely use https://www.wilddog.com. For HTTPS websites, switch to HTTPS for the user’s HTTP access and create a new connection.

But there are two obvious drawbacks to this process:

  • The first two RTS in the whole communication process are meaningless;
  • Using insecure HTTP communication in case you are submitting sensitive data.

HSTS emerged to solve these problems. In addition to saving HTTPS communication RT and enforcing HTTPS usage, HSTS also includes:

  • Prevent man-in-the-middle attacks based on SSLStrip;
  • In case there is an error in the certificate, the error is displayed and the user cannot avoid the warning.

The working mechanism of HSTS is described as follows: After HSTS is configured on the server, it carries the HSTS field in the HTTP header returned to the browser. After obtaining the information, the browser will internally redirect all HTTP requests to HTTPS. Without any network process.

Most browsers now support HSTS perfectly, and you can check out the details for each browser and version at http://caniuse.com/#search=HSTS. But HSTS is flawed and does not work for clients visiting the site for the first time. To solve this problem, look at the HSTS preload List, which we’ll cover next.

HSTS preload list

What is the HSTS preload list?

HSTS Preload List is the HSTS preload list in Chrome. The sites in this list are automatically converted to HTTPS when accessed using Chrome. Firefox, Safari, and Edge also use this list.

How to join HSTS Preload List?

Not only is it easy to join the HSTS Preload list, But Chrome also encourages HTTPS sites to join it. Application of methods and conditions to be met on the https://hstspreload.appspot.com website has details.

The conditions I add to the HSTS preload list are excerpted below:

  • Valid certificates (if sha-1 certificates are used, they must expire before 2016);
  • Redirect all HTTP traffic to HTTPS;
  • Ensure HTTPS is enabled for all subdomains, especially the WWW subdomain

At the same time, the output HSTS response header must meet the following conditions:

  • Max-age takes at least 18 weeks and 10,886,400 seconds
  • IncludeSubdomains parameter must be specified
  • The preload parameter must be supported

So, a typical response header that satisfies an HSTS preload list is: add_header strict-transport -Security “max-age=31536000; includeSubDomains; Preload “;

The time from application to approval varies from a few days to a few weeks. It took three days to apply for the domain name Wilddog.com. After application, you can query the latest status in https://hstspreload.appspot.com, can also be input in the Chrome browser address box “Chrome: / / net – internals / # HSTS” view. Below is the output of the wilddog.com domain name query.

It’s worth noting that it takes a while before stable Release is approved for inclusion in Chrome, as it has to go through Canary, Dev, Beta, and Stable Progression.