HTTP Strict Transport Security (HSTS) – Better Security for Applications

The world of computer security is escalating faster than many could ever have imagined to an extent that today, more security experts are joining the race against some of the smartest cyber attackers around the globe. Talking of smart attackers, no one is surely hacker proof even when deploying some sophisticated defense mechanisms designed. However, HTTPS seems a great weapon to protect users against cyber attackers.

A great example is HTTPS which promises better security when communicating through the web, but did you know that some clever attackers can still circumvent this seemingly secure protocol? Well, one computer security researcher known as Moxie Marlinspike showed the world one way to do so back in 2009. In a presentation to BlackHat, Moxie introduced us to an HTTPS vulnerability we should all be wary of better known as SSL stripping.

To get a better understanding of this vulnerability, you should perhaps understand what HTTPS is all about and how is it different to HTTP. Now, you may have typed HTTP:// on your browser at one point when surfing the web without knowing what this acronym really means. HTTP stands for Hypertext Transfer Protocol and it is just a set of rules used by your browser to communicate with a server. HTTPS, on the other hand, is an improvement to HTTP in the sense that the communication is made through a secure tunnel otherwise known as Secure Socket Layer (SSL) or Transport Layer Security (TLS).

Overview of HTTPS:

In principle, HTTPS uses a Symmetric key encryption system for communication between the server and the client. In this sort of mechanism, the client and server are required to share a key and other encryption algorithms before they can communicate.

For authentication purposes, HTTPS leverages public key infrastructure to ensure that the communicating parties are who say they are. The infrastructure is thus responsible for setting up, distributing and revoking certificates. In case you are lost then, certificates are what individuals and companies have to pay for in order to deliver their sites over SSL.

To be precise, certificates are files that use digital signatures to tie up a machine’s public key with an identity. Such a signature on a certificate translates to someone vouching that a given public key belongs to a given organization.

Certificates are in place to associate a given domain with a given public key thus preventing snoopers from presenting public keys purporting to be the server the client is looking to access.

To cut this long cryptographic story short, it means that whenever you are using HTTPS to access communicating on the Internet, your communication is secure from attacking prying around, at least before some vulnerabilities were discovered one of them being SSL Stripping. So, what is SSL Stripping?

SSL Stripping: A Trick to Defeat HTTPS

In SSL Stripping, the traffic from your machine can be routed via proxy server created by a hacker in some sort of a Man in the Middle (MITM) attack. In other words, if you are target victim, an attacker can establish a connection between your machine and the server meaning that all the traffic from your machine will pass through the attacker’s machine that acts as the proxy.

The real magic with this attack is that your browser will most likely not depict any SSL errors and you will have no idea that the attacker is in place. An HTTPS connection between a browser and server is thus downgraded to HTTP and the effects can be detrimental.

Say you want to transfer your money using an online banking service. Naturally, you will enter the URL to access the service in your browser. If in the background the attacker is connected to your machine, the attacker will first wait for a response from the server, which may be a login page, then it will modify the response from the server from HTTPS to HTTP. The trick here is that the proxy server establishes an HTTPS connection to the server to ensure that no eyebrows are raised.

After modifying the response, the attacker will send the HTTP response to your browser and from there onwards, your address to the banking service is insecure or rather, your requests go out in plain text. The attacker is then able to collect data and credentials as the server thinks that it has successfully established a successful connection with your browser.

The Solution: HSTS

There is a solution in what is known as HSTS (HTTP Strict Transport Security) – a security policy mechanism designed to protect against protocol downgrade and cookie hijacking attacks. With HSTS, web servers require that browsers communicate with them via HTTPS and never through HTTP.

A Brief History of HSTS

HSTS was published as RFC 6797 back in the year 2012 on the approval by the IESG (Internet Engineering Steering Group). It was first submitted as an internet draft in 2010 where the name of the specification was changed from Strict Transport Security to HTTP Strict Transport Security. It is also worth mentioning that the original authors of the specification are Jeff Hodges, Collin Jackson, and Adam Barth.

HSTS Mechanism

In this specification, a server will implement HSTS policy by simply giving a header over HTTPS while headers supplied over HTTP are ignored. In simple terms, it tells the browser not only to enable HSTS but also to remember it for a period of time e. g

Strict-Transport-Security: max-age=31536000;

The maximum age is specified in seconds thus 31536000 is equivalent to one leap year. The browser will now know that HSTS is enabled and it will always use HTTPS connections even when a connection is made via HTTP. This will also save the user from the nuisance of having to click through warnings about invalid certificates.

How HSTS Works in Browsers?

Consider the below figure. Here, the user sends a request for a web page from the HSTS secured host on HTTP. However, the HSTS host will inevitably redirect the user to an already secured page and hence the secure connection is built.

HSTS

Advantages of HSTS to Enhance The Security:

Web sites having partial or no SSL at all, having non-secured as well as secured contents are prone to security threats. Employing HSTS not only aids to the security but also provides an invisible cover securing from the attacks caused due to the loopholes in SSL installation in following ways:

Make all the links HTTP to HTTPS: A directive named “includeSubdomains” makes secure the entire browser requests that link to the website including the subdomains. This specialty solves the problem caused due to the partial invocation of SSL and from the mixed content, which uses HTTP links for some scripts and images.
Abolishment of unsecured connections: Many users prefer ignoring the security warnings. Having HSTS in store, communication is automatically stopped even if the user has avoided the warning and hence decreasing the range of potential attacks.
Converting unsecured URL references: Enforce replacement of HTTP with HTTPS in any of the URLs.
Applying limitations to the ‘secure environment’: Enhances the confidence of the website owners by availing the website in secure mode only.
Defense against Cookie Forcing: Cookie forcing attack is a type of MITM attack and with HSTS, there is “includeSubdomains” mode that saves the browser against such type of attack.

HTTPS and HSTS:

You should perhaps understand about HTTPS and the difference between HSTS and HTTP. Now, you may have typed HTTP:// on your browser at one point when surfing the web without knowing what this acronym really means. HTTP stands for Hypertext Transfer Protocol and it is just a set of rules used by your browser to communicate with a server. HTTPS, on the other hand, is an improvement to HTTP in the sense that the encoded communication is made through a secure tunnel otherwise known as Secure Socket Layer (SSL) or Transport Layer Security (TLS).

HSTS Limitations: HSTS Stripping

HSTS is easy to add to a domain. However, you are not protected until the browser establishes a connection to a given domain- the HSTS header can be stripped in the user’s first visit. Thankfully, the likes of Google Chrome, Mozilla, Microsoft Edge and Internet Explorer have limited this breach by including a list preloaded HSTS sites. HSTS preload list is just a list of sites that get STS enabled automatically even at first visits. Most of these browsers allow users to submit their domains if they meet some standards.

One of the requirements is that HTTPS is enabled in the root domain and all subdomains. It is also required that the HSTS policy covers all sub-domains with a long max-age and a preload flag to indicate the user consents to preloading. The challenge though is the fact that the preloaded list cannot scale over the entire web.

One probable solution to this would be perhaps to use DNS records to declare HSTS policy whilst establishing access to them securely through DNSSEC.

Privacy Issues: HSTS Super Cookies

HTTP Strict Transport Security (HSTS) tells a website that it should have the secure connection. If a user visits a site that has HSTS feature, the browser will collect this flag and assure for the future secure visit. Thus, the user will be redirected to HTTPS even he typed HTTP in the address bar.

HSTS protects the user from being snooped but malicious vectors can store this unique number to track the web browser in near future. This is done by testing if a request for the site is redirected or not. Common browsers treat HSTS tracking differently. Think of it this way, normal cookies are not shared with the sites you visit and browsers afford you the chance to delete them in case you feel that they could be used to track your activities.

Given that HSTS is security based it implies that they are not designed for tracking but who knows how they may be misused! Some browsers have however somewhat found a way to mitigate such vices in that they erase HSTS flags whenever you erase any cookies.

Best Practices

To reap the most out of HSTS, the following practices should always be upheld:

HSTS hosts should always declare the policy at their top-level domains. A valid HSTS header for preloading, in this case:
```
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
```
It is also vital to deploy policy for https://domain.gov but not for https://www.domain.gov. This will ascertain that HSTS for parent domain is set in a way that will protect users from cookie injections from an MITM attacker.

HSTS is certainly palatable in providing security benefits to users in a world where hostile networks are spread all over. Well, it might not be a flawless solution but it is a route that any organization can take in a bid to curb the intensifying number of cyber attackers.