Http Strict Transport Security (HSTS) is a vital web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It is an industry-standard and widely adopted method to ensure web browsers always connect to a website over a secure HTTPS connection. HSTS is designed to eliminate the security risks associated with redirecting users from insecure http:// URLs to secure https:// versions.
When a web browser recognizes that a website has enabled HSTS, it enforces the following crucial security measures:
- Automatic HTTPS Connections: The browser automatically upgrades all attempts to connect to the website via HTTP to HTTPS. This happens even if a user types
http://in the address bar or clicks on anhttp://link. - Bypass Insecure Certificate Warnings: HSTS prevents users from bypassing browser warnings related to invalid SSL certificates. This is critical because attackers often exploit user complacency towards security warnings to compromise their connections.
Websites enable HSTS by sending a special HTTP header, the Strict-Transport-Security header, in responses over HTTPS connections. This header instructs the browser on how to handle future connections to that domain.
In its simplest form, an HSTS policy directive instructs the browser to activate HSTS for the specific domain and its subdomains for a defined period, specified in seconds using the max-age directive:
Strict-Transport-Security: max-age=31536000;For the most robust and highly recommended security configuration, the HSTS policy should encompass all subdomains and include a directive indicating the domain’s intention to be included in browser “preloading” lists:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadWhen implementing this comprehensive HSTS policy, keep these points in mind:
- Policy Deployment Domain: The HSTS policy should be deployed on the root domain (e.g.,
https://yourdomain.com), and not on thewwwsubdomain (e.g.,https://www.yourdomain.com). - Subdomain HTTPS Support: It is essential that all subdomains associated with the primary domain fully support HTTPS. While subdomains are not required to have their own independent HSTS policies, they must be accessible via HTTPS to ensure seamless and secure browsing.
Further details on configuring HSTS policies on popular web servers are provided below.
The Genesis of HTTP Strict Transport Security
The concept of Strict Transport Security was first proposed in 2009, largely inspired by Moxie Marlinspike’s demonstration of the ‘SSLStrip’ attack. This demonstration highlighted how malicious actors on a network could downgrade secure HTTPS connections to insecure HTTP, exploiting vulnerabilities in common redirects. Recognizing the severity of this threat, major web browser developers quickly adopted HSTS, and it was officially standardized as RFC 6797 in 2012.
The core problem that HSTS effectively addresses is the inherent vulnerability that persists even when websites implement HTTPS. Users can still inadvertently or unknowingly attempt to connect over plain HTTP due to several reasons:
- Default HTTP Protocol: When a user types a domain name (e.g.,
yourwebsite.com) into the browser’s address bar, browsers by default attempt to connect usinghttp://. - Legacy HTTP Links: Users might click on outdated or shared links that mistakenly use
http://URLs. - Malicious Network Interception: In hostile network environments, attackers can actively intercept and rewrite
https://links tohttp://, forcing insecure connections.
Websites that prioritize secure HTTPS connections often still listen for incoming traffic on port 80 (HTTP) to redirect users to the HTTPS version of the site. For example, a typical server response to an HTTP request might look like this:
$ curl --head http://yourwebsite.com
HTTP/1.1 301 Moved Permanently
Location: https://yourwebsite.com/This initial HTTP redirect is a critical security weak point. It provides an attacker with a window of opportunity to intercept the connection and potentially steal sensitive information, such as session cookies from previous secure sessions, or maliciously redirect the user to a phishing website designed to mimic the legitimate site.
HSTS mitigates this risk by instructing the browser to remember that a site should only be accessed over HTTPS. By sending the Strict-Transport-Security header over a secure HTTPS connection, the website effectively tells the browser to enforce HTTPS for all future interactions. For example, a secure connection to a website with HSTS enabled might return headers like this:
$ curl --head https://yourwebsite.com
HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubdomains; preloadIn this scenario, any subsequent attempts to access http://yourwebsite.com will be automatically upgraded by the browser to https://yourwebsite.com without even making an insecure HTTP request.
The max-age directive, set to one year (31536000 seconds) in the example above, dictates how long the browser should remember and enforce the HSTS policy. The policy is refreshed each time the browser receives the HSTS header again during a secure HTTPS visit. As long as a user visits https://yourwebsite.com at least once within the max-age period, their browser will continue to enforce the HSTS policy, providing ongoing protection.
HSTS Preloading: Extending Initial Protection
For HSTS to be effective, a user’s browser must first receive the HSTS header from the website over a secure HTTPS connection. This presents an initial vulnerability: users are not protected by HSTS until after their first successful HTTPS connection to the domain. This “first visit” problem is a significant limitation.
Furthermore, in many scenarios, a direct “first visit” to the root HTTPS domain (e.g., https://yourdomain.com) might never occur. Common examples include:
- Redirects to
wwwSubdomains: Many websites redirect directly fromhttp://yourdomain.comtohttps://www.yourdomain.com. - Redirect-Only Domains: Some domains are used solely for redirection purposes, redirecting directly from
http://yourdomain.comtohttps://destination.com.
In such cases, https://yourdomain.com is never directly accessed, and connecting browsers will not receive an HSTS policy with the includeSubDomains directive that would apply to the entire domain zone.
To overcome this initial vulnerability, the Chrome security team developed the “HSTS preload list.” This is a curated list of domains that are hardcoded into Chrome and other browsers. Domains on this list have HSTS enabled automatically from the very first visit, even before the browser has interacted with the website.
Major browsers like Firefox, Safari, Opera, and Edge have also adopted and incorporated Chrome’s HSTS preload list, making it a broadly supported feature across the web browsing ecosystem.
How to Get Your Domain Preloaded
The Chrome security team provides a public submission process that allows website owners to submit their domains to the HSTS preload list. To be eligible for preloading, domains must meet a stringent set of requirements:
- Complete HTTPS Coverage: HTTPS must be enabled on the root domain (e.g.,
https://yourdomain.com) and all subdomains (e.g.,https://www.yourdomain.com). This is particularly important for thewwwsubdomain if a DNS record exists for it. This requirement extends to all subdomains, including those used exclusively on internal networks (intranets). - Comprehensive HSTS Policy: The HSTS policy must include all subdomains (
includeSubDomainsdirective), specify a substantialmax-agevalue (typically one year or longer), and include thepreloaddirective to explicitly signal consent for preloading. - HTTP to HTTPS Redirection: The website must implement a redirect from HTTP to HTTPS, at least on the root domain, to guide users towards the secure version of the site.
A typical valid HSTS header configuration suitable for preloading would look like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadLooking ahead, as the web progressively migrates to full HTTPS adoption and browsers begin to phase out support for plain HTTP, the HSTS preload list (and potentially HSTS itself) might eventually become redundant.
However, until that future state is realized, the HSTS preload list remains a simple yet highly effective mechanism for enforcing HTTPS security across an entire domain from the outset.
HSTS as a Force for Organizational HTTPS Adoption
While HTTP Strict Transport Security offers significant security advantages for website visitors, especially those on potentially compromised networks, it also serves as a powerful organizational tool for enforcing and verifying HTTPS compliance.
When a domain owner implements the recommended HSTS policy on their base domain with includeSubDomains and preload directives, they are making a definitive statement: “Every component of our web infrastructure is served over HTTPS, and will persistently remain so.” They are also granting browsers explicit permission to rigorously enforce this policy going forward.
This declaration acts as a clear, auditable commitment, providing organizations undergoing HTTPS migration a tangible way to mark domains as definitively “secured.”
Considering broader implications, preloading HSTS for entire top-level domains (TLDs) is technically feasible, as Google pioneered with the .google TLD. For relatively small, centrally managed TLDs, like .gov, achieving full TLD-wide HSTS preloading may become a realistic future goal, further enhancing overall web security.
Configuration for Common Web Servers
Implementing HSTS involves configuring your web server to send the Strict-Transport-Security header in HTTPS responses. The configuration method varies depending on the web server software you are using.
On nginx, you can add an add_header directive within the appropriate virtual host configuration block. For example, for https.cio.gov, which is hosted on nginx, the following configuration snippet, derived from these HTTPS rules, sets the HSTS header:
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload;' always;For Apache web servers, you can use the Header directive to always set the HSTS header. Add the following line to your Apache virtual host configuration or .htaccess file:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"Microsoft IIS (Internet Information Services) does not utilize .htaccess files. IIS applications are configured using a central web.config file. For IIS 7.0 and later, the following web.config file example demonstrates how to configure secure HTTP to HTTPS redirection with HSTS enabled for HTTPS connections:
<configuration>
<system.webServer>
<rewrite>
<rules>
<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>
</rules>
</rewrite>
</system.webServer>
</configuration>Generally, the key is to configure your web server to send a custom HTTP header named Strict-Transport-Security with the value max-age=31536000; includeSubDomains; preload (or a variation tailored to your specific needs).
For configuration instructions on other web servers, refer to their respective documentation.
