How secure is redirecting user from http://normal.bank.com to https://secure.bank.com?

Question

I have an application. Which works on http, http://normal.bank.com. But for log-in, performing any action, etc. I am rediecting user to https://secure.bank.com, where user can login and perform action. Is this is still vulnerable to MIM attack? What are the precautions?

Answer 1

Yes, you are vulnerable to MITM attacks due to the fact that you are starting out with an unencrypted web application. This is where the attack takes place, as the attacker would be able to modify any references to https://secure.bank.com and replace them with http://secure.bank.com. The attacker would then intercept your data, and relay the contents to the actual secure connection at https://secure.bank.com

It is highly suggested to force SSL from the very beginning of the session, and you should make sure to only advertise the secure URL.

Answer 2

Is this is still vulnerable to MIM attack?

Yes, it is, because you'd probably go with session-cookies that might be sniffed through a browser-plugin like firesheep or man-in-the-middle'd easily.

What are the precautions?

Best practice nowadays is to have your whole application run over HTTPS because:

• secure cookies don't work in a mixed environment
• MITM-attacks do work in a mixed environment
• ensuring the authenticity of your website to its users doesn't work in a mixed environment
• no need to think about HTTP-resources in a HTTPS-page and ugly browser-alerts

To ensure HTTPS throughout the whole site:

• create 2 virtualhost-configs, one for http: and one for https:
• in your http config, use a redirect from http://site/resource to https://site/resource as the only pattern in this config, so if someone types in http://site/somepath it will always get redirected to the secure site
• in your https config, use a HTST header to help ensure (browser-based) that your user visits your site always via HTTPS

Everything else, like login-page-encryption-only is out-of-date; search for "firesheep"

Answer 3

After visiting http://normal.bank.com, an attacker can replace all links to https://secure.bank.com with links to http://secure.bank.com. When the user clicks on http://secure.bank.com, the MITM will happily connect to the server via HTTPS and serve the contents back to the client via HTTP. No matter what redirection precautions used here, the whole redirection can prevented by the MITM.

In conclusion, yes, you're still vulnerable to MITM attacks.

Answer 4

I'm going to buck the trend here and say it is acceptable to redirect like this.

It is true that a user is vulnerable to MITM if they go to http://secure.bank.com/ and continue to use the site without further checks on certificates, URLs, etc.

However, this is an issue of user behaviour, and not something you can fix server-side.

Lets just think for a minute how you might try to fix this server-side. Rather than issue a redirect you could show an informational page, perhaps with a strongly worded warning "To access this site securely you must use https://secure.bank.com/" Or you could have the web server only listen on port 443 and reject port 80.

Now what happens if an attacker has full control of a user's network? When the user goes to http://secure.bank.com/ the attacker redirects them to https://secure.bank.com.attacker.com/ and presents a phishing page. Or perhaps they insert a phishing page directly into http://secure.bank.com/ Either way, an experienced and alert user could detect this, but many users will continue.

It doesn't make any difference how the real http://secure.bank.com/ behaves - the attacker can do whatever they like.

So ultimately this is a user training issue. And the behaviour of the site can influence this. The vast majority of times a user visits the site, they will visit the real site and not a MITM attack. If the site automatically redirects them, this does nothing to discourage them using the http URL in the future. If they get a warning message, or the site simply does not work, they will quickly learn to use the https by default.

But how responsible are you as a site operator to train your users like this? The reality is that the vast majority of sites do redirect from http to https like this. From a business point of view, why make your site more difficult to use than a competitors? If it's just you making this stand, are you really going to have an effect on general user behaviour?

For those reasons, on balance, I recommend that most sites do redirect from http to https in this way.

To lock this down as much as possible, I recommend you setup the redirect so that http://secure.bank.com/ redirects to https://secure.bank.com/ - stripping the rest of the URL.

Answer 5

It wasn't explicitely mentioned so far, thus this late answer. Websites switching between HTTP and HTTPS are inevitably prone to SSL-strip. A good explanation you can find here:

SSL-strip presentation from Moxie Marlinspike

Some important points:

• It is the first request that makes the difference. Whenever the user starts with HTTP as the first page, then SSL-strip can talk to the user with HTTP and to the site with HTTPS. A switching site will prevent the user from choosing HTTPS for the first request.
• This is where the HSTS header jumps in. If you already visited the site earlier from a secure connection, the header will tell the browser to call the site with HTTPS only for future requests. If you visit the site for the first time, the HSTS header cannot help.
• If the user cares, he can start with HTTPS (typing the url with https:// into the browser bar), this makes SSL-strip impossible on SSL-only sites.

Answer 6

I wrote a blog post about it a few months back. In my blog post I showed how redirecting traffic from http to https could potentially dangerous depending on the mechanism selected. I proposed HSTS (HTTP Strict Transport Security).

http://blog.michaelhidalgo.info/2013/09/redirecting-http-traffic-to-https-why.html