Netstat -vat by Sean Michael Kerner (bio )

A command line view of IT

« Microsoft IE7 flaw was to be expected | Sean Michael Kerner Blog | Black Hat : Persistent web browser storage a risk? »

Black Hat : Hacking SSL with sslstrip

By Sean Michael Kerner on February 18, 2009 10:35 AM

From the 'think SSL is secure?' files:

WASHINGTON D.C We all rely on SSL and HTTPS to secure our web transactions. That's why Moxie Marlinspike's session at Black Hat DC on SSL/HTTPS attacks just blew my mind and has me 'concerned' to say the least.

Marlinspike demonstrated how a new tool he has developed called sslstrip - can trick browsers into thinking they are on an SSL/HTTPS secured site when in fact they are not.

The implication is that all the traffic from the regular HTTP site could then be easily collected by an attacker since the information is not secured.

"Lots of time the security of HTTPS comes down to the security of HTTP and HTTP is not secure," Marlinspike told the capacity crowd.

Marlinspike is no stranger to getting around SSL security. In 2002 he released the -sslsniff - tool that could be used in a man in the middle attack to inject an illegitimate SSL certificate into an HTTP stream, tricking a user into thinking they were on an the legitimate SSL secured site (when in fact they were not).

So how do you protect yourself? Read more after the jump.

Marlinspike also claimed that in a limited 24 hour test case running on the anonymous TOR network (and without actually keeping any personally identifiable information) he intercepted 114 yahoo logins – 50 gmail logins, 9 paypal, 9 linkedin and 3 facebook. So apparently the tool works - and works well.

As for how to protect against sslstrip Marlinspike didn't have many ideas - but those in the audience did.

Among them was noted DNS security researcher Dan Kaminsky who suggested that DNSSEC could be used to validate a domain and perhaps force users to use the legitimate SSL/HTTPS secured version.

In response to a question I asked Marlinspike about what browser vendors should do he responded:

"Browser vendors cannot make HTTP more secure, it's too late for that. When you have a secure protocol that relies on an insecure protocol than just attack the insecure."

He added however that their is an answer but it's not one that he thinks will actually happen.