New security recommendation also improves SEO

Why Was HSTS Introduced?

HTTP is commonly used over various transports, with the Transmission Control Protocol (TCP) being the most typical. However, TCP does not offer protection for integrity, confidentiality, or secure host identification. This shortcoming led to the creation of Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS). SSL/TLS adds an encryption layer between application protocols and TCP, known as HTTPS.

User agents, such as web browsers, generally follow various local security policies to determine how to interact with a host. This decision is based on a negotiation between the server, user preferences, and their communication method (HTTP or HTTPS). However, some user agents permit users to proceed with interacting with a website even if a secure connection cannot be established. This can occur if a TLS certificate’s trust chain is unvalidated, expired, or the TLS host’s domain name is incorrectly stated in the TLS certificate.

This behavior is referred to as click-through insecurity. Allowing users to continue using a website without HTTPS can maintain user satisfaction but also introduces vulnerabilities that expose users to cyber attacks, particularly man-in-the-middle attacks (MITM attacks), downgrade attacks, and session hijacking attacks.

SSL-Stripping

As HSTS enables websites to declare that they are only accessible through secure connections, it prevents users from connecting via any HTTP connection. This helps mitigate a security vulnerability known as SSL-stripping.

SSL-stripping is a downgrade attack introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk, “New Tricks for Defeating SSL in Practice.” A downgrade attack targets a computer system or communications protocol, causing it to abandon its encrypted connection (HTTPS) in favor of an older, unencrypted one (HTTP), usually for backward compatibility with older systems.

In an SSL-stripping attack, a man-in-the-middle intercepts web traffic and redirects it from the secure HTTPS version of a website to an unencrypted HTTP version. This attack remains effective largely because many websites do not use TLS/SSL certificates, making it unclear (without prior knowledge) whether the absence of HTTPS is due to an SSL-stripping attack or a lack of a TLS certificate.

Moreover, there are no alerts to notify users during the downgrade process, making the attack difficult to detect even for vigilant users. The creation of a tool by Marlinspike to automate this attack further underscores the significant cybersecurity risk it poses.

Session Hijacking

Session hijacking, also known as cookie hijacking, is another vulnerability enabled by click-through insecurity.

Session hijacking involves exploiting a valid computer session to gain unauthorized access to information or services. This is especially relevant for web developers since cookies are commonly used to maintain sessions on many websites.

If a website does not flag its cookies as Secure, instructing user agents to only send cookies over HTTPS, they can be easily stolen by an attacker. Non-Secure cookies are returned to the host regardless of transport security, making them vulnerable to man-in-the-middle attacks.

Once an attacker obtains these cookies, they can impersonate the user on a legitimate website.

How Does HSTS Work?

HSTS allows web servers to declare that all interactions by web browsers and other user agents must occur over HTTPS connections, not insecure HTTP connections.

A server can implement an HSTS Policy by supplying a response header over an HTTPS connection (HSTS headers sent over HTTP are ignored). The HSTS header is named “Strict-Transport-Security” and specifies a period during which the user agent should only access the service via HTTPS requests.

When a site is first accessed using HTTPS, it returns the Strict-Transport-Security header. The browser records this information so that future attempts to load the site using HTTP automatically use HTTPS. Once the expiration time specified by the Strict-Transport-Security header elapses, the next attempt to load the site via HTTP will proceed normally instead of automatically using HTTPS. However, whenever the Strict-Transport-Security header is delivered to the user agent, it updates the expiration time for that site, allowing sites to refresh this information and prevent the timeout from expiring.

If necessary, web servers can disable HSTS by setting the max-age to 0 (over an HTTPS connection) to immediately expire the HSTS header, thus allowing access via HTTP requests. For example, a server could send a header requesting that future requests for the next year only use HTTPS via Strict-Transport-Security: max-age=31536000.

When a web application issues an HSTS Policy to user agents, conforming user agents behave as follows:

• Any insecure links are automatically turned into secure links (e.g., http://example.com/ will be modified to https://example.com before accessing the server).
• If a secure connection cannot be ensured (e.g., the server does not have a valid certificate), the user agent will terminate the connection and not allow the user to access the website.

The key takeaway is that an HSTS Policy prevents click-through insecurity by not allowing the end user to use an insecure connection.

What are HSTS Deployment Best Practices?

If your site is committed to HTTPS and you want to preload HSTS, you must:

1. Serve a valid certificate.
2. Redirect HTTP to HTTPS on the same host, if you are listening on port 80.
3. Serve all subdomains over HTTPS.
4. Support HTTPS for the www subdomain if a DNS record for that subdomain exists.
5. Serve the HSTS header on the base domain for HTTPS requests with the following requirements:
   • The max-age must be at least 31536000 seconds (1 year).
   • The includeSubDomains directive must be specified.
   • The preload directive must be specified.
6. If serving an additional redirect from your HTTPS site, that redirect must include the HSTS header (rather than the web page it redirects to).

Recommended steps to start:

1. Examine all subdomains and nested subdomains of your site and ensure they work over HTTPS.
2. Enable HSTS for all HTTPS responses and gradually increase the max-age in stages. During each stage, check for broken pages, monitor your site’s metrics, fix any issues that arise, and wait the full max-age of the stage before proceeding. Use the following header values:
   • 5 minutes: Strict-Transport-Security: max-age=300; includeSubDomains
   • 1 week: Strict-Transport-Security: max-age=604800; includeSubDomains
   • 1 month: Strict-Transport-Security: max-age=2592000; includeSubDomains
3. Once confident there are no issues, increase the max-age to 2 years and submit your site to the HSTS Preload list with the preload directive:
   2 years: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

You can add your website to the HSTS Preload list via hstspreload.org. This is what the Chromium Projects want to see in a preload submission.