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.