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)
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:
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)
trict-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.
- 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.
- 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:
- Phishing Attack: Rather, it complements many existing phishing defenses by instructing the browser to protect session integrity and long-lived authentication tokens.
- 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.”