HSTS is one of the measures used to reduce the possibility of various passive and active attacks, such as man-in-the-middle (MITM). In addition, it serves to provide a more secure connection between clients and servers. Read more below!
What is HSTS?
HTTP Strict Transport Security (HSTS) is a web security policy that ensures that browsers always connect to websites via HTTPS. Part of its purpose is to remove the need to redirect users from HTTP to HTTPS website versions or secure any such redirects.
This is achieved via the HSTS header sent by the server back to the client at the beginning of the connection. This header informs the browser that after the first visit, which HSTS does not cover, it should interact with the website only via HTTPS.
The Strict Transport Security header also prevents users from ignoring browser warnings about invalid or insecure SSL/TLS certificates.
How does HSTS work?
When users visit a website with the HSTS policy enabled, they will usually first make an HTTP request to the server. Then, depending on the setup, they will either arrive at an HTTP version or, in a more secure scenario, be redirected by the server to the HTTPS version of the website via a 301, 302, or 307 redirects. The client will then reconnect to the HTTPS version of the website.
At this stage, the server will send the HTTP Strict-Transport-Security response header over the HTTPS connection. In addition, the header will include different parameters about connecting to the website subsequently.
In its most secure and recommended form, the header will instruct the browser to remember the HSTS policy for a certain amount of time, also known as the max-age directive. Typically that period will be at least a year, though specified in seconds (see example below). It will also intrust the browser to consider the policy as applying to all of the website’s subdomains and preload the website. This is what the header looks like in this form:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadFrom that moment on, no HTTP connections to the website are allowed. If a user attempts to load a page or other content via HTTP, the browser is required to try an HTTPS request instead. If this is not possible, the resource will not be accessible, and the connection attempt will be terminated. Moreover, if the server’s certificate is not trusted, the policy must also prevent users from accessing the website or application.
The purpose of the preload parameter is to avoid creating the vulnerability associated with visiting the website for the first time. Websites that comply with several requirements can submit a request to be included in a browser’s preload list (see Chrome’s HSTS Preload list). When included in the list, a browser will load the HTTPS version of a website already at the first attempt of accessing by a user.
While there are limitations to this approach, since hardly all websites can be included in preload lists, it is one way of addressing the above vulnerability.
HSTS Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
How secure is HSTS?
The HSTS header helps prevent several different cyber attacks. This includes SSL stripping – a form of man-in-the-middle attack (MITM), session hijacking (also known as cookie hijacking or sidejacking) attempts, and various downgrade attacks. This is particularly the case if a website is added to preload lists.
However, certain limitations and vulnerabilities still exist if the preload option is unavailable. For example, the first request to a website is still vulnerable to an attack if an insecure protocol is used, such as plain HTTP, even with a redirect request to HTTPS. There are few workarounds to this issue. One possible way of addressing this is to use DNS records that declare HSTS Policy and access these records safely through DNSSEC.
The HSTS header, regardless of its setup, cannot prevent the use of fraudulent domains that trick users into visiting them. This can be achieved via DNS spoofing, another type of MITM, or by attackers using domain names closely resembling a website’s domain name.
Finally, HSTS cannot prevent attacks against the TLS protocol itself. Attacks such as BEAST and CRIME target vulnerabilities inherent in specific versions or implementations of TLS and are not covered by the policy.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to enable HSTS?
Below you can find examples of how to enable HSTS on different platforms.
It’s important to note that when deploying, HSTS policy should be declared at the base domain (sometimes called the root domain, though there is a difference). In our case, that would be https://crashtest-security.com/ instead of https://www.crashtest-security.com/.
To cover subdomains, the includeSubDomains directive should be utilized. But for this to work, all subdomains associated with the base domain must naturally also support HTTPS.
Use the following guides to set the correct header enabling HSTS.
Let’s Encrypt
With Let’s Encrypt, it is straightforward to enable HSTS. When creating a new certificate, just ad the –HSTS flag. If your certificates are already generated by Let’s Encrypt, just run the same command and choose “Attempt to reinstall this existing certificate” as the first option. This will reuse your certificate and enable HSTS stapling.
certbot run -d [DOMAIN] --staple-ocsp --hstsnginx
On Nginx you need to update your SSL configuration which is usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS) to include the correct header with the add_header directives:
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";
listen 443;
server_name example.org;
root /usr/share/nginx/www;
index index.html index.htm;
ssl on;
ssl_certificate /etc/nginx/ssl/example.org/server.crt;
ssl_certificate_key /etc/nginx/ssl/example.org/server.key;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;
}Strict Transport Security Apache
On Apache you need to update your SSL configuration to include the correct Header directives. Add this to the virtual host configuration in /etc/apache2/sites-enabled/domain.conf or /etc/httpd/sites-enabled/domain.conf:
<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=31536000"
ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/example.com/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/example.com/apache.key
SSLCACertificateFile /etc/ssl/ca-certs.pem
SSLUseStapling on
</VirtualHost>
</IfModule>FAQs
What does HSTS mean?
HSTS stands for HTTP Strict Transport Security. This web security policy guarantees that clients only access the HTTPS version of a website instead of the HTTP one. It serves as protection against man-in-the-middle attacks such as SSL stripping, downgrade attacks, and more.
Does HSTS provide complete security?
No, HSTS has its limitations. For example, if a website is not part of a browser’s preload list, users are still vulnerable to an attack the first time they visit the website. HSTS also cannot protect against SSL/TLS protocol attacks. That said, HSTS provides very high security and significantly limits the possibility of attacks against direct HTTP connections.
