Maximize Website Security with the Strict-Transport-Security Header

In today’s digital landscape, securing web communications is paramount. HTTP Strict Transport Security (HSTS) is a vital web security policy mechanism that helps protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. This widely adopted standard ensures that web browsers interact with a website exclusively over secure HTTPS connections, enhancing both security and user trust. HSTS effectively eliminates the vulnerabilities associated with insecure HTTP to HTTPS redirects.

When a browser recognizes that a website has implemented HSTS, it enforces two critical security measures:

• Automatic HTTPS Connections: Browsers automatically convert any attempt to access the site via http:// to https://. This applies even when a user clicks on an http:// link or types the domain name without specifying the protocol in the address bar.
• Strict SSL/TLS Certificate Validation: HSTS disables the option for users to bypass browser warnings related to invalid or untrusted SSL/TLS certificates. This prevents users from accidentally proceeding to a potentially insecure site, even if they encounter certificate errors.

Websites activate HSTS by sending a specific HTTP response header, Strict-Transport-Security, over an HTTPS connection. This header instructs the browser about the site’s HSTS policy.

In its most basic form, an HSTS policy directs the browser to enable HSTS for the exact domain or subdomain from which the header is received. The max-age directive specifies the duration, in seconds, for which the browser should remember and enforce this policy.

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

For robust security, the strongest and highly recommended HSTS configuration includes two additional directives: includeSubDomains and preload.

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

When deploying this enhanced HSTS policy, it’s essential to consider the following:

• Policy Placement: The HSTS policy should be set on the root domain (e.g., https://domain.com), not just on subdomains like https://www.domain.com. This ensures that the policy covers the entire domain and its subdomains.
• HTTPS Support Across Subdomains: Crucially, all subdomains associated with the primary domain must support HTTPS. While individual subdomains don’t need to broadcast their own HSTS policies, they must be accessible via HTTPS to comply with the includeSubDomains directive.

Further details on how to configure an HSTS policy on popular web servers are provided below.

The Genesis of Strict Transport Security

The concept of Strict Transport Security was first proposed in 2009, driven by concerns highlighted by security researcher Moxie Marlinspike’s demonstration of the “SSLStrip” attack. This attack illustrated how malicious actors could intercept and downgrade a user’s secure HTTPS connection to insecure HTTP, exploiting vulnerabilities in the common practice of HTTP-to-HTTPS redirects. Recognizing the critical need for a robust solution, major web browser developers quickly embraced HSTS, leading to its standardization as RFC 6797 in 2012.

The fundamental issue that HSTS addresses is the inherent vulnerability in relying solely on redirects to enforce HTTPS. Even when a website is configured to use HTTPS, users can still inadvertently initiate connections over plain HTTP in several scenarios:

• Direct Domain Entry: When a user types a domain like “example.com” into the browser’s address bar, browsers typically default to http://.
• Outdated or Insecure Links: Users might click on older hyperlinks embedded in emails or websites that mistakenly use http:// URLs.
• Network-Level Attacks: In hostile network environments, attackers can actively intercept and rewrite https:// links to http://, forcing users onto insecure connections.

Websites aiming to enforce HTTPS often still maintain HTTP listeners to redirect users to the secure HTTPS version. For example, a typical server response to an HTTP request might look like this:

$ curl --head http://example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

This redirect mechanism, while seemingly helpful, is inherently insecure. It presents a window of opportunity for attackers to intercept the initial HTTP request and potentially steal sensitive information, such as session cookies from previous secure sessions, or maliciously redirect the user to a phishing site mimicking the legitimate domain. This initial insecure connection is the weakness HSTS is designed to eliminate.

HSTS provides a solution by instructing the browser to automatically upgrade all future connections to HTTPS. When a server responds to an HTTPS request with the Strict-Transport-Security header, it informs the browser to remember this policy for a specified duration. For instance:

$ curl --head https://example.com
HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

In this scenario, the browser will enable HSTS for example.com. Consequently, any subsequent attempts to access http://example.com will be automatically transformed by the browser into direct requests for https://example.com, ensuring a secure connection from the outset.

The max-age directive, set to one year (31536000 seconds) in the example above, dictates the policy’s lifespan. Each time the browser encounters the Strict-Transport-Security header on a secure visit, it refreshes the policy’s expiration. Therefore, as long as a user visits https://example.com at least once within the max-age period, they remain continuously protected by HSTS.

HSTS Preloading: Extending Initial Protection

A crucial aspect of HSTS is that a browser must first see the HSTS header to activate its protection. This implies that users are not shielded by HSTS on their very first interaction with a domain. The initial connection is still vulnerable until the HSTS policy is established.

Furthermore, there are scenarios where a user’s browser might never directly visit the root HTTPS domain (e.g., https://domain.com). Consider these common examples:

• Redirect to www Subdomain: Many websites immediately redirect from http://domain.com to https://www.domain.com. In such cases, https://domain.com itself is never directly accessed.
• Redirect to Destination Site: Some domains are solely used for redirects, forwarding http://domain.com directly to https://destination.com. Again, https://domain.com is bypassed.

In both these situations, browsers connecting to these domains will not receive an HSTS policy with the includeSubDomains directive applicable to the broader domain zone, leaving subdomains potentially unprotected on the first visit.

To overcome this “first visit” vulnerability and extend HSTS protection from the very beginning, the Chrome security team pioneered the HSTS preload list. This is a meticulously curated list of domains hardcoded into Chrome. Domains on this list have HSTS enabled automatically by the browser, even on the user’s first visit.

The impact of the Chrome HSTS preload list is amplified because other major browsers, including Firefox, Safari, Opera, and Edge, also incorporate and utilize this same list. This ensures broad, cross-browser compatibility and protection.

Preloading Your Domain: Requirements and Process

The Chrome security team provides a public mechanism for website owners to submit their domains to the HSTS preload list. To be eligible for inclusion, domains must meet stringent criteria:

• Comprehensive HTTPS Support: HTTPS must be enabled not only on the root domain (e.g., https://example.com) but also on all subdomains (e.g., https://www.example.com). This is particularly crucial for the www subdomain if a DNS record exists for it. This requirement extends to subdomains used exclusively within internal networks (intranets).
• Strict and Enduring HSTS Policy: The domain’s HSTS policy must include:
  • includeSubDomains directive to cover all subdomains.
  • A substantial max-age value, typically at least one year (31536000 seconds), to ensure long-lasting protection.
  • The preload directive to explicitly signal the domain owner’s consent to preloading.
• HTTP to HTTPS Redirection: The website must implement a redirect from HTTP to HTTPS, at least on the root domain, to guide users to the secure version.

A valid HSTS header suitable for preloading would look like this:

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

In the long-term vision of a fully HTTPS-enabled web, as browsers evolve to phase out support for plain HTTP and default to HTTPS connections, the HSTS preload list (and potentially HSTS itself) might eventually become redundant.

However, until that future arrives, the HSTS preload list stands as a remarkably effective and straightforward method for enforcing HTTPS across an entire domain from the very first connection.

HSTS as a Catalyst for Organizational HTTPS Adoption

Beyond its direct security benefits for website visitors, particularly those on potentially compromised networks, Strict Transport Security serves a valuable secondary purpose: as an organizational forcing function and compliance tool.

When a domain owner adheres to best practices, implementing an HSTS policy on the base domain with includeSubDomains and preload, it signifies a strong commitment: “Every facet of our web infrastructure is served over HTTPS, and will perpetually remain so.” This declaration, coupled with the preload directive, grants browsers the authority to rigorously enforce this policy moving forward.

This clear, auditable commitment provides organizations overseeing HTTPS migration a definitive way to mark domains as “HTTPS-compliant” and “secure”. It fosters accountability and simplifies the tracking of HTTPS adoption across large web estates.

Looking at a broader scale, the preloading concept can even extend to entire top-level domains (TLDs). Google pioneered this by preloading HSTS for .google. For smaller, centrally managed TLDs, such as .gov, preloading HSTS for the entire TLD could be a future possibility, further strengthening web security at a fundamental level.

Configuration Examples for Common Web Servers

Implementing the Strict-Transport-Security header is straightforward across various web server platforms. Here are configuration examples for popular servers:

nginx:

In nginx, you can add the add_header directive within the appropriate virtual host configuration block. For example, the https.cio.gov website, running on nginx, utilizes these HTTPS rules to set the HSTS header:

add_Header Strict-transport-security 'max-age=31536000; includeSubDomains; preload;' always;

Apache:

For Apache servers, use the Header directive within your VirtualHost configuration or .htaccess file to consistently set the HSTS header:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS (Internet Information Services):

IIS configurations are managed through a central web.config file, rather than .htaccess files. For IIS 7.0 and later, the following web.config snippet demonstrates how to configure both HTTP to HTTPS redirection and HSTS for HTTPS connections:

 <rule>  name="HTTP to HTTPS redirect" stopProcessing="true">  <match url="(.*)" />  <conditions>  <add input="{HTTPS}" pattern="off" ignoreCase="true" />  </conditions>  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />  </rule>  <rule>  name="Add Strict-Transport-Security when HTTPS" enabled="true">  <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />  <conditions>  <add input="{HTTPS}" pattern="on" ignoreCase="true" />  </conditions>  <action type="Rewrite" value="max-age=31536000; includeSubDomains; preload" />  </rule>

In general, the core principle is to configure your web server to include a custom HTTP header named Strict-Transport-Security with the value max-age=31536000; includeSubDomains; preload (or a variation tailored to your specific requirements).

Consult your web server’s documentation for detailed instructions on setting custom HTTP headers.

Resources

• HTTP Strict Transport Security – MDN Web Docs
• HSTS Compatibility – Can I use…
• Strict Transport Security Proposed Standard
• RFC 6797 – HTTP Strict Transport Security (HSTS)
• Moxie Marlinspike – SSLStrip: Demonstrating a Man-in-the-middle Attack
• Chromium HSTS Preload List
• HSTS Preload Submission Form
• W3C TAG Finding: The web MUST be on HTTPS
• nginx HTTPS rules – fisma-ready/nginx