SSLstrip is a very easy tool to use that sits in between a victim and a legitimate website and switches their traffic from HTTPS to HTTP. If they continue to use the website in HTTP, the tool steals their passwords.
The author presented an example data set in 2009 that showed in 24 hours he was able to find a little over 100 passwords by setting up an attack in front of a single TOR router. He further boasted that not a single user stopped using the websites when his tool switched them to a non-SSL page.
The tool has to be on a network such as an open wireless to gather victim traffic. Many have also speculated about compromise of a host internal to an organization. Once a host inside a company has been compromised, then the tool can be installed to redirect local traffic by spoofing ARP tables. The stolen passwords, or other sensitive information, then can be sent back outside the organization.
A paper from George Mason University called “Prototype System to Protect against SSL-Stripping Attacks” suggests SSLstrip attacks can be defeated by forcing secure HTTP traffic using a special proxy. It sits in-between users and a web-site to prevent network traffic from redirection and interception by a rogue proxy like SSLstrip.
The client-side tool needs to be installed on all hosts to be secured on the a business’ or organization’s LAN, and the client’s browser will be configured to route all HTTP traffic through our system. As mentioned above, the routing of HTTPS traffic is not modified. Whenever the client host starts up, the client and server use public key encryption to establish a shared secret key.
When the user makes an HTTP request, the client tool generates a random number to prevent replay attacks, encrypts it along with the HTTP request using the shared secret key, and forwards them to the proxy server
(1). The proxy server stores the random number and forwards the HTTP request to appropriate web server
(2). When a response is received
(3), the proxy server computes a Hash-based Message Authentication Code (HMAC) of the response, using the HMAC-MD5 algorithm
(4). The server then appends the HMAC and the original random number to the HTTP response, encrypts it all
and sends it back to the client
(5). The client verifies both the HMAC and the random number
(6). If both match, the message was not modified in transit. If they do not match, the tool alerts the user to possible tampering.
I tend to agree with Michal on this, just kill unsecured wifi:
http://lcamtuf.blogspot.com/2010/12/unencrypted-public-wifi-should-die.html
I don’t think this solution is particularly useful as it requires additional programs to be installed. Better off using HTTP STS and a mixture of other things to mitigate the problem.
Yes, you are right but I also find some kind of odd and humorous irony that I haven’t yet figured out how to put into words.
A rogue proxy competes against another proxy over who will capture and control HTTP traffic. And a move to secure wifi is a step but it’s no help if SSLstrip gets deployed and run by “additional programs to be installed” on a host inside that secure network (e.g. remote control agent/malware). I guess what I’m saying is that if a proxy is good enough for an attacker, and additional programs are good enough for an attacker…on the other hand it’s the usual odds as an attacker only needs to get a single instance to work, whereas defenders still have to chase and plug every leak.