The Importance of a Proper HTTP Strict Transport Security Implementation on Your Web Server

About 95 percent of HTTPS servers are vulnerable to connection hijacking, opening the door for hackers to launch man-in-the-middle and other devastating cyber attacks. That’s according to a Netcraft study released about a week ago. The reason for this concerning situation? Only 5 percent of HTTPS servers have a correct implementation of HTTP Strict Transport Security.

About HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a method for web applications to ensure they only use TLS to support secure transport. It protects users against passive eavesdropper and active man-in-the-middle (MITM) attacks. It also enforces strict security like preventing mixed content and click-through certificate overrides, and it protects against web server mistakes like loading JavaScript over an insecure connection. HSTS serves as a secure umbrella against all of these attacks.

Web applications should operate under the assumption that a hacker can run MITM over a plaintext HTTP connection for any domain/subdomain, for example with the help of spoofed DNS entries. Hackers cannot, however, intercept valid HTTPS traffic over any of the domains/subdomains. Hence, it is advisable to protect as many domains/subdomains as possible using an appropriate HSTS policy.

Implementing HSTS

There are semantically distinct ways to send HSTS headers, as defined in RFC 6797:

• Strict-Transport-Security: max-age=31536000
  • The HSTS policy is applied only to the domain of HSTS host issuing it and remains in effect for one year.
• Strict-Transport-Security: max-age=31536000; includeSubDomains
  • The HSTS policy is applied to the domain of the issuing host as well as its subdomains and remains in effect for one year.
• Strict-Transport-Security: max-age=0
  • Directs the browser to delete the entire HSTS policy.

HSTS Best Practices

There are a few simple best practices for HSTS:

1. The strongest protection is to ensure that all requested resources use only TLS with a well-formed HSTS header. Qualys recommends providing an HSTS header on all HTTPS resources in the target domain.
2. It is advisable to assign the max-age directive’s value to be greater than 10368000 seconds (120 days) and ideally to 31536000 (one year). Websites should aim to ramp up the max-age value to ensure heightened security for a long duration for the current domain and/or subdomains.
3. RFC 6797, section 14.4 advocates that a web application must aim to add the ‘includeSubDomain’ directive in the policy definition whenever possible. The directive’s presence ensures the HSTS policy is applied to the domain of the issuing host and all of its subdomains, e.g. example.com and www.example.com.
4. The application should never send an HSTS header over a plaintext HTTP header, as doing so makes the connection vulnerable to SSL stripping attacks.
5. It is not recommended to provide an HSTS policy via the http-equiv attribute of a meta tag. According to HSTS RFC 6797, user agents don’t heed http-equiv=”Strict-Transport-Security” attribute on <meta> elements on the received content.

How Qualys Protects

The challenge for most organizations is always to protect consistently over time and at scale. The Qualys Cloud Platform offers tools to help.

Qualys Vulnerability Management (VM) includes a detection (QID 86137) that reports if HSTS is found to be running on a web server. When included in regular scanning and reporting, this QID can provide visibility into the use of HSTS across an organization.

For additional depth, Qualys Web Application Scanning (WAS) performs HSTS analysis in order to not only detect the presence of HSTS on webservers but also more detail on its configuration.

• Qualys WAS detections (QIDs) report the top 10 HTTPS resources for which ‘Strict-Transport-Security’ header is not defined.
• Qualys WAS also reports on max-age value for webservers where HSTS is implemented. Qualys WAS reports (i.e. flags an ‘Information Gathered’ or IG) if max-age for HSTS is set below 120 days.
• Qualys WAS recommends to add includeSubDomains attribute while defining HSTS headers. If the ‘includeSubDomains’ attribute is missing, it’s reported as an IG and not a vulnerability. Adding or eliminating an ‘includeSubDomains’ attribute is quite a tricky decision and ideally falls out of the scope of an automated scanner. Please refer to ‘includeSubDomains’ caveats for details.

In addition to the above, we always recommend to integrate Qualys WAS into your SDLC process. This has many advantages including early detection of HSTS configuration and other security issues. Many studies have shown that bugs (including misconfigurations) are easier and cheaper to fix the earlier they are discovered in the development process, and that they are most expensive to fix in production.

The Preload List

HSTS suffers from a chicken-and-egg problem. If a browser has never visited a specific HSTS-enabled website previously, the browser will be unaware that the website is HSTS enabled and will attempt an HTTP connection that is prone to an SSL stripping attack.  Browsers supporting HSTS have attempted to mitigate the issue by shipping a “pre-loaded” list which is nothing but a list of known HSTS hosts. For example: https://www.chromium.org/hsts has the entire preload list for chrome. Domains included in the preload list of the browser will be configured with HSTS out of the box. To include your web application in the preloaded HSTS list, submit a request to https://hstspreload.appspot.com/.

Use of ‘includeSubDomains’

Using the ‘includeSubDomains’ directive at the top-level domain may not be feasible, for example when one subdomain is present that does not work over HSTS. Possibilities could be the following:

1. It’s expensive to furnish every subdomain server with a valid CA-signed certificate. If HSTS is enabled, the browser prohibits users from using self-signed certificates for any subdomains.
2. Insecure resources will fail to load and break pages that would have worked seamlessly over TLS when no HSTS policy was implemented.

Including the subdomains directive is recommended only when all sites within the organization for the given domain name require TLS/SSL. It’s necessary to evaluate the impact on existing 3rd party services like email or DNS CNAMES for CDNs before adding the ‘includeSubDomains’ directive.

Conclusions

Because HSTS provides protection against a wide array of attacks, is supported widely by browsers, and can be configured with a one-line setting, we strongly recommend its use for all Internet-facing web applications. And whatever tools you use, we recommend incorporating secure coding practices and awareness of HSTS early in your development lifecycle, and ensuring that your developers think about security from day one.