HTTPS Everywhere :: Using HTTP Strict Transport Security

The concept of HTTPS, that is having the web traffic from your browser to the web server over an encrypted channel is widely used over the web. It ensures that no attacker in the middle can grab or modify transmitted information like your cookie data; hence preventing the hijacking of your web session. So, enabling HTTPS limits the capability of an attacker in the middle.

How can Man-in-the-middle (MITM) attacker work around HTTPS ?

Mostly when users wants to browse a website, for instance say bank of america website, they would generally type “bankofamerica” or “www.bankofamerica.com” in their browser address bar. On this browser would basically make an HTTP request to bankofamerica.com i.e. http://www.bankofamerica.com, even though bank website operates as https://www.bankofamerica.com. So, to rectify that bank website can redirect the HTTP request to HTTPS (by issuing a 302 re-direct), but it still leaves your HTTP request to the bank, vulnerable to attack by MITM before the actual redirection happens. The SSL-stripping MITM attack introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk “New Tricks For Defeating SSL In Practice“, exploits this vulnerability. It would be much more safer if the HTTP request can be totally avoided and the browser itself knows that it should connect to the website over HTTPS. This is exactly what HTTP Strict Transport Security (HSTS) is meant to address.

(See the pictorial representation of above explained vulnerability in the figures 1 and 2. Figure 1 shows the normal redirect mechanism of the browser request from HTTP to HTTPS and figure 2 shows that attacker can intercept the initial HTTP request before the redirect to establish himself as MITM)

url-redirect-mitm

figure 2: URL redirect with MITM

url-redirect-normal

figure 1 : 302 URL redirect scenario

How does HSTS operate?

HSTS support is implemented by adding a “Strict-Transport-Security” HTTP header to the server’s response, which will inform the browser that this website would connect only over HTTPS. Henceforth, any further HTTP request to website would be transformed at the client side/browser side itself into HTTPS, hence no network traffic goes over HTTP. So, sending:

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

would instruct the browser that the website sending this header should be accessed only over HTTPS for a year (as per max-age). Thus, the use of this header reduces the attack surface drastically: provided that the initial response (bootstrapping response) by the server reaches the browser without interception.

The website can take another step ahead and specify that all its sub-domains as well would be using HSTS by the use of “includeSubdomains” option as shown in the following example (though use of includeSubdomains is optional)

Strict-Transport-Security: max-age=31556926; includeSubdomains

Currently, HSTS has been implemented in Firefox, Chrome and Opera; though it is still to implemented in IE and Safari. The updated browser trends for HSTS and other features can be seen at BrowserScope.

(Apart from making the sub-domains oblige to HSTS policy, “includeSubdomains” has much more significance attached to it. This is covered in the next post here.)

Can we do something about HSTS Bootstrap MITM problem?

As we have seen that initial response from the web server which has the HSTS header should reach non-intercepted to the browser, in order to ensure complete security from adversary. This problem is referred to as Bootstrap MITM Vulnerability.

  1. One possible solution is to have a pre-loaded list of hosts in the browser for which HSTS would be on-by-default. Firefox and Chrome already support a pre-loaded list of hosts which want HSTS on by default. Chrome’s pre-loaded list can be seen here.
  2. Another potential solution is to include the HSTS information with DNSSec requests itself. Though, I have not come across any references which implement or mention details about it.

What HSTS is not meant for?

HSTS is not meant to prevent against:

  1. Phishing Attack: Rather, it complements many existing phishing defenses by instructing the browser to protect session integrity and long-lived authentication tokens.
  2. Malware: As malicious code executing on the user’s system can compromise a browser session, regardless of whether HSTS is used.

Note:- The HSTS specification published as RFC 6797 is based on the original work by Collin Jackson and Adam Barth as described in their paper “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.

Advertisements

3 thoughts on “HTTPS Everywhere :: Using HTTP Strict Transport Security

    • Basically the idea behind the SSL-stripping attack is to convert a secure HTTPS into unencrypted HTTP. Now, here though the user sees that connection is HTTP there is no way of knowing whether the connection should be secure or not, as not all websites use HTTPS. Thus, HSTS targets to act as a defense against the above attack.

      Moreover, sniffing is a restricted to the same local network and is a smaller use case.

  1. Pingback: Anatomy of “includeSubdomains” directive in HTTP Strict Transport Security Policy | Thoughts Unleashed

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s