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?

  • Possible dupe: security.stackexchange.com/questions/14246/…
    – sleske
    Nov 3, 2013 at 10:03
  • 5
    @sleske No, this is a different case. Here, after login, the user is still in HTTPS.
    – Adi
    Nov 3, 2013 at 10:44
  • 1
    @Adnan: Oh yes, you're right.
    – sleske
    Nov 3, 2013 at 14:34
  • 2
    Just out of curiosity though, is there ever a time where you would want to have an http://normal.bank.com? From what I understand, it should be standard protocol to always have banks and important information in https (and http disabled).
    – krikara
    Nov 4, 2013 at 6:41
  • 1
    @user960567 Yes, they are now using HTTPS everywhere. Now we need to convince them to use HSTS.
    – Moshe Katz
    Nov 6, 2013 at 5:38

6 Answers 6


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.

  • But the site secure.bank.com is not available on http. Is still I am vulnerable? Nov 3, 2013 at 9:39
  • Can you explain a more in simple terms? Thanks Nov 3, 2013 at 9:42
  • I've edited the answer to better explain how the attack might take place. Nov 3, 2013 at 10:16
  • See the above answer Nov 3, 2013 at 11:03
  • 2
    @user960567 The attacker can choose to redirect to secure.hisserver.com, where 'hisserver' looks similarly enough to 'bank' for the user not to notice. My bank does this and I hate them for it. The login is https://secure.bank.com/very/long/uri and the only way to get there is via http://bank.com/login. Horrible.
    – Jan
    Nov 3, 2013 at 12:36

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"

  • 1
    If going to the login page forces a complete new session, will the application be then secured?
    – ComFreek
    Nov 3, 2013 at 14:17

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.

  • 1
    Yes they have different cookies, secure and HttpOnly. Nov 3, 2013 at 11:01
  • @Adnan You didn't take things like sslstrip into account, which work by MITMing the client, showing the client only HTTP links while establishing an HTTPS connection to the server when the client tries to open such a link. Nov 3, 2013 at 15:44
  • @heinrich5991 Incorrect. Please reread the part of the answer starting with "Even if the references to..."
    – Adi
    Nov 3, 2013 at 15:46
  • 1
    @Adnan To be clear: Client requests http://bank.com/, server returns page with link to https://secure.bank.com/ for login, the MITM replaces that link with http://secure.bank.com/ and saves the link for HTTPS requests. The client clicks on login and requests http://secure.bank.com/, MITM changes this to a request to https://secure.bank.com/, server happily returns data, MITM decrypts it and sends it back to the client. Client logs in and MITM is able to intercept login data. Nov 3, 2013 at 15:48
  • 1
    @heinrich5991 Please note the part of the answer where I mention "Secure cookies". Secure cookies are flagged with the "Secure" flag, which means that the cookie will ONLY be passed with an HTTPS request.
    – Adi
    Nov 3, 2013 at 15:52

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.

  • "However, this is an issue of user behaviour, and not something you can fix server-side." yes, you can, and this is called HSTS. but you must ensure to run the while site in HTTPS. Nov 6, 2013 at 7:02
  • 1
    While HSTS is good, it's not supported on Safari or IE, so we really can't rely on a user having an HSTS-compliant browser.
    – paj28
    Nov 6, 2013 at 11:09

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.
  • Nice concise answer. Nov 9, 2013 at 2:26

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).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .