0

If I request our website using HTTP http://example.com, the reponse is 301 Moved Permanently with the Location header set to https://example.com - which, of course, is insecure due to MIM attack.

Is there not a way to just repond to the browser something along "make the same request again but this time over HTTPS" insted of explicitly telling the browser the URL?

I was expecting to find this kind of solution on Troy Hunt's blog post but the only suggestion there is to use HSTS preload (ie. register our site with Google) which we do not want to do.

Viktor
  • 334
  • 1
  • 3
  • 14
  • `Is there not a way to just repond to the browser something along "make the same request again but this time over HTTPS" insted of explicitly telling the browser the URL?` This wouldn't make it any more secure. – tkausl Jan 31 '19 at 12:23
  • As opposed to which solution, @tkausl ? – Viktor Jan 31 '19 at 12:36
  • As opposed to explicitly sending the domain to redirect to. – tkausl Jan 31 '19 at 12:37
  • @tkausl please read the linked blog post to see how redirect is not a good solution and is easily hijacked. – Viktor Jan 31 '19 at 12:44
  • But sending `make the same request again but this time over HTTPS` to the browser _has the exact same security issues_. – tkausl Jan 31 '19 at 13:10

1 Answers1

1

HTTP Strict-Transport-Security (HSTS) allows you to send a HTTP Header to say “next time you use this domain - make sure it’s over HTTPS even if the user types http:// or uses a link beginning http://“.

In Apache it is set with the following config:

Header always set Strict-Transport-Security "max-age=60;"

This sends the message telling the browser to remember this header for 60 seconds. You should increase this as you confirm there are no issues. A setting of 63072000 (2 years) is often recommended.

So this is more secure than a redirect as it happens automatically without needing an insecure HTTP request to be sent which could be intercepted, read and even changed on an insecure network.

For example let’s imagine you have logged on to your internet banking previously on your home WiFi, the browser has remembered the HSTS setting and then you visit your local coffee shop. Here you try to connect to the free WiFi but actually connect to a hackers WiFi instead. If you go to your internet banking with a HTTP link, bookmark or by typing the URL, then HSTS will kick in and you will go over HTTPS straight away and the hacker cannot unencrypt your traffic (within reason).

So. All is good. You can also add the includeSubDomains attribute:

Header always set Strict-Transport-Security "max-age= 63072000; includeSubDomains"

Which adds extra security.

The one flaw with HSTS is it requires that initial connection to load this HTTP header and protect you in future. It also times out after the max-age time. That’s where preload comes in. You can submit your domain to the browsers and they will load this domain’s HSTS setting into the browser code and make this permanent so even that first connection is secure.

However I really don’t like preload to be honest. I just find the fact it’s out of your control dangerous. So if you discover some domain is not using HTTPS (e.g. http://blog.example.com or http://intranet.example.com or http://dev.example.com) then as soon as the preload comes into affect - BANG you’ve forced yourself to upgrade these and quickly as they are inaccessible until then. Reversing from browser takes months at least and few can live with that downtime. Of course you should test this, but that requires going to https://example.com (instead of https://www.example.com) and using includeSubDomains to fully replicate what preload will do and not everyone does that. There are many, many examples of sites getting this wrong.

You’ve also got to ask what you are protecting against and what risks you are exposing yourself to? With a http:// link a hacker intercepting could get access to cookies (which the site can protect against by using the secure attribute on cookies) and possibly intercept the traffic by keeping you on http:// instead of upgrading to https:// (which is mostly mitigated with HSTS and is increasingly flagged by the browser anyway). Remember that even on an attackers WiFi network the green padlock means the connection is secure (within reasonable limitations). So as long as you look for this (and your users do, which is more difficult I admit) the risks are reasonably small. This is why the move to HTTPS everywhere and then HTTPS by default is so important. So for most sites I think HSTS without preload is sufficient, and leaves the control with you the site owner.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • I think you formulated my question with the 1st half of this answer a lot better than I managed to do. `However I really don’t like preload to be honest. I just find the fact it’s out of your control dangerous. ` - that's basically what I was getting at. `The one flaw with HSTS is it requires that initial connection to load this HTTP header and protect you in future.` - and this is the reason I am asking this question. – Viktor Feb 01 '19 at 08:51
  • And preload is the way around that flaw. If there was a better way than preload then it wouldn’t need to exist. However I argue preload is overkill for most sites and HSTS offers good additional protections to redirect with little enough risk. – Barry Pollard Feb 01 '19 at 09:02