HSTS Policies are usually distributed by a web server as a HTTP Response Header. Whilst some sites enforce HTTPS by issuing a redirect, many do not implement HSTS and leave the user vulnerable to a MiTM attack. HSTS Policies can be added to Google Chrome manually, by the user, to enforce HTTPS communications and mitigate the risk, even if the server doesn't issue the policy.
In my previous blog on HSTS you can find a lot more detail on what HSTS is and how it is implemented. Even though the specification for HSTS has been published for almost a year as of the time of writing, there are still very few sites that implement it. Fortunately users of Google Chrome can manually add a HSTS Host to the browser even if the site doesn't issue a HSTS Policy. This is useful for any site that enforces HTTPS using redirects as they are still vulnerable to a MiTM attack. By manually adding the host as a HSTS Host, the browser will afford the user all the protection of a HSTS Policy without the server having to issue one.
Adding A HSTS Host
Adding a HSTS Host to Google Chrome is relatively straight forward. The only concern is whether or not the host site is capable of using HTTPS exclusively to serve its content. If you navigate to a http:// version of the URL and you are automatically redirected to a https:// version then the chances are that at least the top level domain is suitable to be a HSTS Host. Check to see if the site is already issuing a HSTS Policy and if not you can manually create one. Copy and paste the following into a new tab in Google Chrome and hit Enter.
This will load up Chrome's HSTS configuration page. From here you can add, remove and query Chrome's database for storing HSTS Hosts. In my previous blog on HSTS I showed the HSTS Policy for Twitter and Facebook. From this page you can query the database and verify that they are indeed HSTS Hosts.
A great candidate for manually adding as a HSTS Host are online banking websites. I checked most of the sites for high street banks in the UK in my previous blog and not a single one of those I checked was issuing a HSTS Policy. This leaves their users vulnerable to MiTM attacks like those I have demonstrated with SSLstrip and considering the specification has been published for almost a year, I would expect to see some uptake.
For this example I have decided to use the online banking website for Barclays, http://ibank.barclays.co.uk is the URL. I can verify that the site isn't a HSTS Host by checking the response headers for the request to load the page and by querying the Chrome database of HSTS Hosts. The initial request to http:// is redirected to https:// which is then redirected again to https://bank.barclays.co.uk/olb/auth/LoginLink.action where the login form is located. Here are the results.
When adding the HSTS Host I could specify barclays.co.uk and subdomains or the bank.barclays.co.uk subdomain specifically. Whilst barclays.co.uk doesn't redirect to https:// it does support it if entered manually. For that reason I'm going to try specifying barclays.co.uk and subdomains. If you do create a HSTS Host and then start having issues accessing the site using HTTPS you can simply remove it. With that in mind it seems like the best course of action to add the domain name and all subdomains and only revert to specifying subdomains if required. We may as well have as much of our taffic going over HTTPS as possible, right!?
Once the host has been added to the HSTS database you will no longer be able to send a request to the site over HTTP. You can use the Chrome Developer Tools to verify this. Hit F12 and go to the network tab. Now, manually insert http://barclays.co.uk into your address bar and hit enter. If you scroll to the top of the list once the page loads, you will see the HTTP request was never sent. Because the site is now a HSTS Host the browser didn't execute the HTTP request and immediately substituted it with a HTTPS request instead. Now, no matter what happens, you will not be able to communicate with barclays.co.uk, or any of their subdomains, over HTTP!
As the use of HSTS becomes more widespread the need for manual user intervention should become smaller and smaller. Until that time, the manual entry of HSTS Hosts is a great way of enforcing HTTPS communications in place of plugins. The EFF have done a great job with HTTPS Everywhere but you're still dependent on them adding new hosts. The only downside is that the user must add all of the hosts that they wish to be enforced to the list manually. For a few minutes of your time to add important or sensitive websites to the list, it's well worth the trouble!
Short URL: https://scotthel.me/hsts2