Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Possible dupe: security.stackexchange.com/questions/14246/… –  sleske Nov 3 '13 at 10:03
4  
@sleske No, this is a different case. Here, after login, the user is still in HTTPS. –  Adnan Nov 3 '13 at 10:44
1  
@Adnan: Oh yes, you're right. –  sleske Nov 3 '13 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 '13 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 '13 at 5:38
show 3 more comments

6 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
But the site secure.bank.com is not available on http. Is still I am vulnerable? –  user960567 Nov 3 '13 at 9:39
    
Can you explain a more in simple terms? Thanks –  user960567 Nov 3 '13 at 9:42
    
I've edited the answer to better explain how the attack might take place. –  David Houde Nov 3 '13 at 10:16
    
See the above answer –  user960567 Nov 3 '13 at 11:03
1  
@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 '13 at 12:36
add comment

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"

share|improve this answer
1  
If going to the login page forces a complete new session, will the application be then secured? –  ComFreek Nov 3 '13 at 14:17
add comment

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.

share|improve this answer
1  
Yes they have different cookies, secure and HttpOnly. –  user960567 Nov 3 '13 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. –  heinrich5991 Nov 3 '13 at 15:44
    
@heinrich5991 Incorrect. Please reread the part of the answer starting with "Even if the references to..." –  Adnan Nov 3 '13 at 15:46
    
@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. –  heinrich5991 Nov 3 '13 at 15:48
    
@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. –  Adnan Nov 3 '13 at 15:52
show 1 more comment

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.

share|improve this answer
    
"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. –  that guy from over there Nov 6 '13 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 '13 at 11:09
add comment

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.
share|improve this answer
    
Nice concise answer. –  David Houde Nov 9 '13 at 2:26
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.