Why Implement HTTP Strict Transport Security or HSTS

HTTP Strict Transport Security, or HSTS, is a method used by websites and web applications to declare that they can only be accessed over HTTPS, i.e., a secure connection. If a web application declares an HSTS policy, then the browser shall refuse all incoming HTTP connections and prevent the visitors from accepting insecure SSL certificates. As of now, HSTS is supported by most of the browsers; however, some mobile-based browsers fail to implement it efficiently.
HSTS, as a web security standard, as defined in 2012 in RFC 6797. In the RFC document, it was stated that the primary goal of this standard is to avoid MITM attacks that utilize SSL stripping. Using SSL stripping, an attacker forces a browser to connect to a web application or website using HTTP so that they can intercept and sniff packets or modify sensitive information being transmitted between a sender and intended receiver(s). Our experts believe that HSTS is an effective method to protect a web application from cookie hijacking attacks.

How does HSTS work?

As a matter of general practice, we directly enter a website’s URL in the browser and skip the protocol part (either its HTTP or HTTPS). For example, one would enter www.breachlock.com and not https://www.breachlock.com. By default, the browser makes an assumption that the user intends to send the request using the HTTP protocol, and hence, it sends an HTTP request to www.breachlock.com.When this request is received by the web server, it responds with a redirect response (i.e. response code 301) that directs the request to the HTTPS site. Now, the browser sends an HTTPS request to www.breachlock.com and HSTS comes into play with an HTTP response header.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The Strict-Transport-Security header gives a special set of instructions to the browser that are:

• Every incoming connection to this web application and its subdomains must be an HTTPS connection.
• The last statement shall hold true for the next year, e., 31536000 seconds.
• If the browser receives an HTTP request to load any resource, it shall try an HTTPS request only. If HTTPS is not available, the connection must be terminated immediately.

Moreover, a user can also be prevented from initiating a connection if the certificate is not valid. A certificate is considered as “not valid” when it is expired, self-signed, or signed by an unknown certifying authority. In that case, the browser displays a warning that can be bypassed. However, if a web application has implemented HSTS, the browser does not allow a user to bypass the warning. To access such a web application, it needs to be manually removed from the HSTS list maintained by the browser.

Is HSTS completely secure?

Just like any other security control or mechanism, HSTS cannot be deemed as entirely secure. When a user accesses a website for the first time, HSTS is out of the equation. If a website attempts to add an HSTS header to an incoming HTTP connection, the header is ignored as an attacker can either add or remove headers during a man-in-the-middle attack. HSTS header is not trusted unless it is added via HTTPS connection.
Further, the ­max-age HSTS tag gets refreshed every time a user’s browser reads the header and the maximum duration is two years. Hence, if a user visits a website after a duration of more than two years, the said website will be treated as a new website.
An additional method for protection can be using the HSTS preload list. If a website is added to the preload list, the browser first checks its internal list so that a website is never accessed via HTTP – not even when it receives the connection request for the first time. The Chromium project maintains a list of websites using HSTS and this list is used by major browsers such as Chrome, Firefox, Safari, Opera, IE11, and Edge.
As of now, the known method to bypass an HSTS header is an NTP-based attack. If a computer is vulnerable to an NTP attack, an attacker can trick the computer into expiring the HSTS policy and access a web application once with HTTP requests.

Adding a domain to the HSTS preload list

For adding a web application domain to the HSTS preload list, the domain shall meet specific standard requirements that are listed below.

1. The domain and its subdomains shall have valid certificates and up-to-date ciphers.
2. If they can be accessed via HTTP, all requests are redirected to HTTPS.
3. Use the Strict-Transport-Security header over HTTPS along with the max-age tag with at least one-year duration (31536000 seconds), and include includeSubDomains and preload
4. Submit the request for your domain using the form available at https://hstspreload.org.

It must be noted that the preload list is distributed as a hard-coded resource along with new browser versions. It cannot be accessed or downloaded by a browser. This essentially means that adding a new entry to the list can take a significant amount of time while the same holds true for removing a domain for the preload list. The decision-makers must ensure that if a web application is to be added to the preload list, they must be able to maintain full HTTP Strict Transport Security(HSTS) access to all resources associated with the said application for an extended duration. Otherwise, the said web application might become totally inaccessible.