Update [3/22/2011]:
A great solution to properly address this problem is to use HTTP Strict Transport Security. This effectively instructs the browser to only interact with the webpage over HTTPS. The browser will prevent a user from sending any requests to the site over HTTP.
Content Security Policy (CSP Blog Post)
OWASP TLS Cheat Sheet
Many sites do their best to secure the login page. They post to https and even use an https landing page to accept the username and password. These items are great and exactly what should be happening. The next step is often to disable http access to the login page or automatically redirect http to https. Just in case a user types in http://mybank.com instead of https.
Here is where we hit a problem. Once a user makes an http request they have lost. We must assume from a security perspective that there is always an active-man-in-the-middle attack. Assuming otherwise is placing a false trust on the infrastructure. So, the MitM simply takes the http request, intercepts the response (404 or 300 redirect) and inserts their own content. The easiest attack? Simply modify the response to a 200 and insert the correct html from the site's https login page.
Now the victim sees what they expect, a login page on their bank's website. The only problem is that the site never redirected to https. So the user enters the username and password and its transmitted in the clear. The MitM then happily sniffs that info and passes it to the actual site. The user never knows their creds have been stolen.
The above scenario is a simplified version of the new attack tool SSLStrip which was recently unveiled at Black Hat. The SSLStrip tool actually does a bit more by modifying the post location to a similar looking url which is accomplished with punycode. However, this is just icing on the cake. The fundamental issue above is a large enough issue on its own.
How to we protect ourselves?
We can say that we need to keep educating our users to look for HTTPS, but realisticly that's not the best defense. We should have technical controls to protect the user. What can we do? Aside from hoping the user always directly types in https://mybank.com, the answer is nothing. But this isn't realistic. Users see that their site automatically redirects them so they happily type in the least amount of characters "mybank.com".
Our only hope is to begin modifying the browser itself. I propose we add a setting to the browsers which allows a user to specify the website of their bank to the browser. The browser will then never access a page from that domain unless it is HTTPS.
Will this protect the user? Yes. Will it also break other things or be a burden to the site? Probably. But what's it going to be? Are we going to adapt or continue to let our users get compromised?
-Michael Coates