0

I can't understand why its dangerous, someone told me that an attacker can hijack before it loads the HTTPS version, but hows that possible.

Ashwin
  • 69
  • 7
  • Possible duplicate of [How secure is redirecting user from http://normal.bank.com to https://secure.bank.com?](https://security.stackexchange.com/questions/44843/) or [Redirect from HTTP to HTTPS; SSLStrip](https://security.stackexchange.com/questions/112873/) – Steffen Ullrich Jun 03 '18 at 06:16
  • Above questions is asking how secure it is and mine is why it is considered dangerous? – Ashwin Jun 03 '18 at 08:23
  • Have you even read the answers? Since they discuss the problems with the redirect, i.e. the part you described in your question as *"... an attacker can hijack before it loads the HTTPS version, but hows that possible"*. – Steffen Ullrich Jun 03 '18 at 12:32

1 Answers1

4

First, to answer your question:

It's not that redirecting HTTP to HTTPS is more dangerous than NOT redirecting to HTTPS. Redirecting HTTP to HTTPS is in fact extremely important!

The thing is, if somebody is hitting a security-sensitive site over HTTP, something is already wrong. The user should be using HTTPS from the beginning. Of course, web browsers are unhelpful here - they default to HTTP unless the user specifically types the https:// part before the domain name - but that's legacy behavior that we basically just have to deal with.


The solution to this problem is something called HTTP Strict Transport Security (HSTS). HSTS is a way for a website to tell a browser "hey, this is a secure site, don't you ever try connecting to me over insecure HTTP, OK?". All modern browsers (including IE11, though not older versions of IE) support HSTS, meaning they will only use HTTPS for that site (even if the user typed http:// instead; the browser changes it to https:// before sending the request).

HSTS does have one weakness: for the server to tell the browser to never use HTTP, the browser has to already have connected to the server. The first such connection is the most likely one to made over HTTP rather than HTTPS anyhow (because the user just typed the domain name into the URL bar), so an attacker almost always has at least one shot to hijack the connection (more on that in a sec). Not good. The solution to that is to use HSTS Preloading, which is a list built into all HSTS-supporting browsers of sites that the owner has specifically requested to never be visited over HTTP; the browsers are pre-configured to have HSTS already enforced for those sites.

It is worth noting that, for inclusion in the HSTS preload list, your site MUST redirect any HTTP request to HTTPS. That must be the first thing it does, in fact, before doing any other redirect or serving any content.


The answer to "how is that possible?" is a clever attack called "SSL stripping" (see previous Q on Security.StackExchange). In a nutshell, when the browser connects to a site over HTTP, it has no way of knowing whether it is actually talking to the server it meant to reach, or some attacker who has redirected or intercepted the request. That attacker (if present) could then make an HTTPS connection to the real site, sending along the same request it got from the user (just over the secure connection this time), and then decrypt the HTTPS response and send it back to the user via plain-text. In the process, the attacker can record and also modify the responses (and the requests), doing things like changing any HTTPS link into an HTTP link, so that the user doesn't click some link or button and switch to a secure connection (which the attacker could not intercept). If the user doesn't notice that they're on HTTP instead of HTTPS - which they can only do by looking at the URL bar closely; the site looks otherwise identical - the user might do something like log into the site, which would let the attacker see the user's credentials. An attacker who is doing this is termed a "Man In The Middle" or MITM.

CBHacking
  • 40,303
  • 3
  • 74
  • 98