Table of contents of the article:
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that allows websites to declare themselves accessible only over secure connections. This helps protect websites and users from protocol downgrades and cookie hijacking attacks.
Why was HSTS introduced?
HTTP is used on various transports, typically the Transmission Control Protocol (TCP).
However, TCP does not provide host integrity, confidentiality, or secure identification protection.
This led to the development of Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS). SSL / TLS provides a layer of encryption between application protocols and TCP, commonly known as HTTPS.
In general, user agents (such as web browsers) will use various local security policies to decide how to interact with a host, based on a negotiation between the server, user preferences and their communication method (HTTP or HTTPS ).
However, some user agents allow users to choose to continue interacting with a website when they are unable to establish a secure connection. This could occur when a TLS certificate's chain of trust is not validated, when it has expired, or when the domain name of the TLS host is displayed incorrectly in the TLS certificate.
This behavior is called click-through insecurity.
While offering users the ability to continue using a website despite the fact that the lack of HTTPS may satisfy users, it can introduce attack vectors that leave users open to certain types of cyber attacks, particularly man-in-the-middle attacks. (MITM attacks), downgrade attacks and session hijacking attacks.
Since HSTS allows websites to declare that they are only accessible over a secure connection, they can prevent users from connecting to them over any HTTP connection.
This prevents a security vulnerability known as SSL-stripping.
SSL stripping is a downgrade attack introduced by Moxie Marlinspike in his 2009 BlackHat federal speech New Tricks for Defeating SSL in Practice .
A downgrade attack is a form of cryptographic attack on a computer system or, in this case, a communication protocol that causes its encrypted (HTTPS) connection to be abandoned in favor of an older unencrypted (HTTP) connection that is typically provided for backward compatibility with older systems.
SSL stripping is implemented as part of a man-in-the-middle attack where web traffic is intercepted and redirected from the secure HTTPS version of the website to an unencrypted HTTP version.
The main reason this attack continues to be successful is that many websites still do not use TLS / SSL certificates. This makes it impossible to know (without prior knowledge) if a website's lack of HTTPS is due to an SSL stripping attack or because they don't have a TLS certificate.
Furthermore, there are no alerts to alert the user during the downgrade process, making the attack difficult to detect even for the most vigilant user.
With the creation of a tool by Marlinspike to fully automate this type of attack, it poses a real cybersecurity risk.
Session Hijacking - Session Hijacking
Session hijacking or cookie hijacking is another vulnerability enabled by click-through insecurity.
Session hijacking exploits a valid computer session to gain unauthorized access to information or services.
This is particularly relevant for web developers as cookies are used to maintain a session on many websites.
If a website doesn't mark its cookies as Safe, telling user agents to send cookies only over HTTPS, they can easily be stolen by an attacker. Because unprotected cookies are returned to the host regardless of transport security, leaving them open to man-in-the-middle attacks.
Once an attacker has access to cookies, they can then impersonate the user on a legitimate website.
How does HSTS work?
HSTS allows web servers to declare that any interaction by web browsers and other user agents must be conducted over HTTPS connections and not insecure HTTP connections.
A server can implement an HSTS policy by providing a response header over an HTTPS connection (HSTS headers sent via HTTP response headers are ignored). The HSTS header is named Strict-Transport-Security and also specifies a period of time during which the interpreter must access the service only via HTTPS requests.
This means that the first time you access a site via HTTPS it returns the Strict-Transport-Security header, the browser logs this information, so future attempts to load the site via HTTP automatically use HTTPS.
After the expiration time specified by the Strict-Transport-Security header expires, 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 will update the expiration time for that site, so that sites can update this information and prevent the timeout from expiring.
Should it be necessary to disable HSTS, web servers can set the maximum age to 0 (on an HTTPS connection) to immediately expire the HSTS header, allowing access via HTTP requests.
For example, a server might send a header requesting future requests for next year to use HTTPS only via Strict-Transport-Security: max-age = 31536000
When a web application sends an HSTS policy to user agents, compliant user agents behave as follows:
- Any unsecured links are automatically transformed into secure links (e.g. http://example.com/ will be changed to https://example.com before accessing the server)
- If a secure connection cannot be guaranteed (e.g. the server does not have a valid certificate), the user agent will terminate the connection and will not allow the user to access the website.
The most important thing to understand is that an HSTS policy prevents click-through insecurity by not allowing the end user to use the insecure connection.
What is an example of a situation involving HSTS?
Imagine your staff member uses a free Wi-Fi hotspot at a coffee shop and starts surfing the web, visiting your organization's payroll system.
Unfortunately, the access point they are using is actually an attacker's laptop and they are intercepting the original HTTP request and redirecting your employee to a clone of your payroll system instead of the real one, exposing the personally identifiable information. (PII) of your employees.
If your payroll system uses HSTS and your employee has visited it once using HTTPS, their browser will know it's only using HTTPS, preventing this type of man-in-the-middle attack.
What are the limitations of HSTS?
A fundamental limitation of using HSTS is that a user who cannot connect via HTTPS will not be able to use the site.
Also, because the HSTS policy is communicated in a response header, it requires the user agent to first visit the website to learn that it uses HSTS.
This means that the initial request remains unsecured from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel.
This will also apply to the first request after the activity period specified in the max-age HSTS (sites generally set a period of several days or months depending on user activity and behavior).
There is widespread browser support for HSTS, including Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, and Safari, to address this limitation by preloading HSTS policies from the HSTS preload list. The HSTS list contains well-known websites that support HSTS and are distributed with the browser, so use HTTPS for the initial request for the websites listed.
Since this approach can never scale to the entire web, there have been discussions for being able to declare HSTS in DNS records and access them in
Additionally, HSTS is ineffective against typosquatting domains, DNS-based attacks, and man-in-the-middle attacks that serve traffic from an artificial domain that isn't on the HSTS prefetch list.
And since HSTS relies on TLS itself, it also relies on the security of TLS.
Read RFC 6797 for a more in-depth discussion of general HSTS security considerations.
What are the best practices for deploying HSTS?
If your site is HTTPS bound and you want to preload HSTS, you need to:
- Provide a valid certificate
- Redirect HTTP to HTTPS on the same host if you are listening on port 80
- Serve all subdomains over HTTPS
- You must support HTTPS for the www subdomain if a DNS record exists for that subdomain
- You need can HSTS header in the base domain for HTTPS requests:
- The maximum age must be at least 31536000 seconds (1 year) must be at least
- The includeSubDomains directive must be specified
- The preload directive must be specified
- If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the webpage it redirects to)
We recommend that you start with the following steps:
- Review all subdomains and nested subdomains on your site and make sure they work on HTTPS.
- Enable HSTS for all HTTPS responses and gradually increase the maximum age. During each stage, check for broken pages, monitor your site's metrics, and fix any issues that occur, then wait for the maximum age of the stage before moving forward. You can use the following header values:
- 5 minutes - Strict transport safety: max-age = 300; includeSubDomains
- 1 week - Strict transport security: age-max = 604800; includeSubDomains
- 1 month - Strict-Transport-Security: max-age = 2592000; includeSubDomains
- Once you are sure there are no problems, increase the maximum age to 2 years and submit your site to the HSTS preload list with the preload directive:
- 2 years - Strict transport safety: age-max = 63072000; includeSubDomains; preload
- You can add your website to the HSTS preload list via https://hstspreload.org/.
This is what Chromium projects want to see in a preload submission.
What is the history of HSTS?
The HSTS specification (RFC 6797) is based on the original work of Collin Jackson and Adam Barth in a paper titled ForcedHTTPS: Protecting High-Security Web Sites from Network Attacks , released in 2008.
On September 18, 2009, PayPal, Jackon and Barth published an updated version of the protocol outline in the original document, available here .
This led to the latest "community version" of the then-named "STS" specification released on December 18, 2009, with revisions based on community feedback.
Finally, on November 19, 2012, the HSTS specification (RFC 6797) was published after being approved on October 2, 2012 by the Internet Engineering Steering Group (IESG), a body composed of the president of the Internet Engineering Task Force (IETF) and area directors.
Which browsers support HSTS?
- Chromium and Google Chrome from version 126.96.36.199
- Firefox from version 4; with Firefox 17, Mozilla integrates a list of websites that support HSTS
- Opera from version 12
- Safari from OS X Mavericks version 10.9
- Internet Explorer 11 on Windows 8.1 and Windows 7 when KB 3058515 is installed
- Microsoft Edge and Internet Explorer 11 on Windows 10
- BlackBerry 10 Browser and WebView from BlackBerry OS 10.3.3