Subverting SSL with SSLstrip
At the recent Black Hat security conference, independent hacker Moxie Marlinspike gave a speech about his new tool sslstrip and the techniques that it uses to subvert SSL on a network (a write up can be found at http://www.itpro.co.uk/609932/website-danger-as-hacker-breaks-ssl-encryption and the tool and a video of the presentation can be found at http://www.thoughtcrime.org/software/sslstrip/). The presentation talked about techniques to subvert SSL directly through browser flaws using CA constraints in addition to talking about his tool, sslstrip, which can be used to perform a man-in-the-middle attack to view all network traffic of a user.
Marlinspike presented his results from using several of the different techniques and found that, by running a TOR endpoint, he was able to get hundreds of email usernames and passwords and well as more important logins such as for banks. He was even able to get various credit card numbers through this technique. Marlinspike also presented a technique of using homographs from different languages as well as a foreign language domain (for example, var.cn) to present a user with a valid looking address and certificate after proxying their traffic. His techniques largely rely on human error and a lack of knowledge, but they prove to be ultimately effective with the safeguards that are currently in place.
The root of the problem of the man-in-the-middle attack is the way that browsers and web sites currently deal with SSL encryption on web pages. On the browser side, a myriad of harsh warnings pop up when a conflicting or self-signed certificate is used, but there is only a lack of indicators in the case of no SSL. This leads to users not noticing the lack of a lock icon, the https in the address, or some sort of highlighting in the address bar and using the compromised page as they normally would. On the web site side of the problem, many sites that use SSL, transfer to the encrypted page after using a non-encrypted http page to get user credentials. This allows the attack to commence by getting proxying the traffic that a user would encounter after a normal login while listening in to all the web traffic.
In order to prevent the problem in the future, a few different approaches should be taken. For web sites, going entirely with SSL and not transferring from an http page could mitigate the issue. Also, overall user education to help users understand the issues of what the address bar is and what the different indicators around the chrome of the browser mean could allow the users to be more alert to attacks such as this. Finally, a change in the way the browser operates by alerting the user in encryption status for web pages from session to session could help to make an attack like this more visible.