HSTS

HSTS – Header, Preload, Checker, Apache, Nginx, Policy and so on…

Introduction

When you visit a site that uses HTTPS, you automatically trust that your data will be kept safe, but this isn’t always the case. Imagine the following scenario; you join a free Wi-Fi access point at a café and log in to check the balance of your bank account. Noticing a green padlock next to the address bar of your bank’s URL, you feel confident that the site is secure and type in your username and password. However, did you know that by doing so, you may have just sent your personal information to a hacker? Unfortunately, the access point you connected to was actually an attacker’s laptop, and they intercepted your HTTP request redirecting you to a fake clone version of your bank’s site, exposing your private data. The good news is that by implementing HSTS (HTTP Strict Transport Security) on your site, you can prevent these types of security breaches.

The main importance of HSTS is to make sure that websites are protected against man in the middle-attacks, hacks, encryptions or any other types of criminal activity. Before further exploring how to implement HSTS and prevent this type of malicious activity, let’s remind ourselves of the basics.

HTTP

Short for HyperText Transfer Protocol, HTTP is a group of standards that allows the exchange of information via the world wide web. When accessing a site that has HTTP at the beginning of its address, any data sent to and from that site won’t be encrypted and will be vulnerable to eavesdropping attacks.
The standards required to communicate between applications are constantly evolving and improving. This allows the internet to become more advanced and a safer place to transfer data.

HTTPS and SSL

HyperText Transfer Protocol Secure (HTTPS) is important for websites that pass sensitive information, such as online stores that ask for credit card details, or sites that require login details. HTTPS is enabled by installing an SSL (Secure Sockets Layer) certificate on to a web server. Once an SSL certificate is activated, any data that flows to and from that site will be encrypted. These certificates are monitored by the Certificate Authority and therefore cannot be distributed to online hackers. They will also be tracked if stolen.

In 1994 HTTPS was applied to a Netscape browser as they understood the importance of internet security. HTTPS was further developed to use SSL. The stages below show the progression towards Transport Layer Security (TLS) which is the most widely deployed security protocol used to communicate between applications today: –

The history of Transport Layer Security

HSTS

If HTTPS is considered secure, then why do we need HSTS, and how can a potential attacker steal data from a site?
In 2010 Eric Butler discovered that website owners were creating home pages with HTTPS, but as soon as users logged into the site, it would relegate them back to HTTP. To raise awareness, Eric decided to create FireSheep, a tool used to intercept specific login sessions.

This then lead to Moxie Marlinspike’s tool SSLStrip where he proved his theory that just because you are forcing sites from HTTP to HTTPS it doesn’t mean they are secure and can still be hacked. The tool allows interception from HTTP traffic and acts as a man in the middle (known as the attacker), stripping away the secure connection and logging personal information such as credit cards and passwords and sending it back to the HTTPS site securely.

In response to the threat of ‘Man in the Middle Attacks,’ a protocol called HTTP Strict Transport Security (HSTS) was created. Strict Transport Security was introduced by Moxie Marlinspike in 2009 after he demonstrated how an attacker could downgrade users’ connections and force insecure redirects. This protocol was then taken on by a few major web browsers and finalised as the standard RFC 6797 in 2012. During finalisation, this standard was renamed to the security procedure ‘HTTP Strict Transport Security’, due to it only applying to HTTP connections.

Understanding and Implementing HSTS

As you can see, padlocking your website by using an SSL certificate isn’t enough to keep data safe. So how do you ensure that HSTS is enabled?
Switching it on is a reasonably simple process. HSTS runs on a time-based system, meaning that when you enable it you need to decide how long you can guarantee your site will use HTTPS.
When an HSTS browser communicates with a server that has HSTS configured, it is on the look out for a certain HTTP header that advises the web client must only ever communicate with the server via an HTTPS connection. A max-age value within the header also tells the browser that the server should be accessed over HTTPS for a minimum amount of time. As a general rule of thumb over six months is recommended as a minimum, but the max-age value can go up to a few years.
Now that the web browser has visited the site and received the header, the next time a person navigates to that site the browser will know that it can only be accessed securely over HTTPS for time that the max-age value is set to. Every time the website is visited, the value will be reset.

HSTS Pre-requirements

Unless you use subdomains, you will need to use an extended validation, domain validated, or organisation validated SSL certificate. To cover subdomains, you must use a Wildcard certificate that only covers HTTPS. In addition, make sure that your certificates are working properly by visiting an online SSL checker. You must serve an HSTS header on the base domain for HTTPS requests, and all HTTP links must be directed to HTTPS with a 301 Permanent redirect. Finally, max-age must be set to at least 10886400 seconds (18 Weeks).

Header always set Strict-Transport-Security

NGINX – HSTS Installation

Navigate to your site.conf file and insert the following code:-

NGINX – HSTS Installation

IIS Server – HSTS Installation

The easiest way to add a new header is via the user interface. Run IIS Manager, select your site and then go to HTTP Response Headers. Click add and in the Add Custom HTTP Response dialog, add the following: –

IIS Server – HSTS Installation

Lighttpd – HSTS Installation

Add the following script to your Lighttpd configuration file /etc/lighttpd/lighttpd.conf

Lighttpd – HSTS Installation

Testing HSTS

If you wish to test that HSTS is working correctly on your web applications, simply amend the max-age to 300 in your header code. This will mean that HSTS will expire every five minutes (300 seconds). After you are happy that the five-minute test works as expected, increase the number of seconds to weekly (604800), monthly (2629746) and then finally to two years (63072000).

HSTS Preloading List

Although HSTS works well when a person has previously visited your site, a new visitor won’t be protected. HSTS will only work for people who have already browsed to a site, and new visitors won’t have the HSTS rule that forces them to connect over HTTPS. HSTS preload lists can assist with this issue by hardcoding a list of sites that must be connected using HTTPS only. The Chrome HSTS Preload List at //hstspreload.org/ is a page where you can input HSTS enabled sites (this doesn’t just work for Chrome, it is also a list used as the basis for preload lists used in other browsers too).

Other Considerations

Content Security Policy (CSP) is another option that automatically blocks or upgrades HTTP requests when submitting pages via HTTPS and is worth investigating as an additional security protocol. To find out more about it, check out the following link: – //www.troyhunt.com/the-6-step-happy-path-to-https/

Bypassing HSTS is also sometimes possible via a newer version of SSLStrip2 (also known as SSLStrip+) by exploiting DNS server changes. By adding further detail to the request, the router’s DNS doesn’t understand how to react to it. Further information on this vulnerability can be found via

null-byte.wonderhowto.com/how-to/defeating-hsts-and-bypassing-https-with-dns-server-changes-and-mitmf-0162322/

The tools below can also assist you in implementing and finding out more about HSTS: –

certbot.eff.org/ (automatically enables HTTPS on your website)

securityheaders.io/ (checks if sites are using HSTS or CSP headers)

scotthelme.co.uk/hsts-preloading/ (goes into more detail about HSTS preloading)

report-uri.com (a real time monitoring platform service)

Conclusion

Hopefully, by reading the points above, you will now realise that implementing HTTPS is not enough to secure information that flows to and from your website.
By enabling HSTS and submitting your site to HSTS preload lists, your website’s security will improve, and you will feel far more confident that your client’s data will be kept safe from future hacks.