Free Republic
Browse · Search
General/Chat
Topics · Post Article

Skip to comments.

Hacker pokes new hole in secure sockets layer
The Register ^ | 19 February 2009 | Dan Goodin

Posted on 02/19/2009 10:25:03 AM PST by ShadowAce

Website encryption has sustained another body blow, this time by an independent hacker who demonstrated a tool that can steal sensitive information by tricking users into believing they're visiting protected sites when in fact they're not.

Unveiled Wednesday at the Black Hat security conference in Washington, SSLstrip works on public Wi-Fi networks, onion-routing systems, and anywhere else a man-in-the-middle attack is practical. It converts pages that normally would be protected by the secure sockets layer protocol into their unencrypted versions. It does this while continuing to fool both the website and the user into believing the security measure is still in place.

The presentation by a conference attendee who goes by the name Moxie Marlinspike is the latest demonstration of weaknesses in SSL, the encryption routine websites use to prevent passwords, credit card numbers, and other sensitive information from being sniffed while in transit. Similar to side jacking (http://www.theregister.co.uk/2008/02/01/google_ssl_sidejacking/) attack from 2007 and last year's forging of a certificate authority certificate (http://www.theregister.co.uk/2008/12/30/ssl_spoofing/), it shows the measure goes only so far.

"The attack is, as far as I know, quite novel and cool," said fellow researcher Dan Kaminsky, who attended the Black Hat presentation. "The larger message of Moxie's talk is one that a lot of people have been talking about actually for a few years now: This SSL thing is not working very well."

Marlinspike said SSLstrip is able to work because the vast majority of sites that use SSL begin by showing visitors an unencrypted page and only offer the protection for sections where sensitive information is transmitted. When a user clicks on a login page, for instance, the tool alters the site's unencrypted response so the "https" is changed to "http." The website, however, continues to operate under the assumption the connection is encrypted.

Two-fold Technique

SSLstrip manages to fool the user into believing he has an encrypted connection with the intended website through several clever slights on hand. First, the tool uses a proxy on the local area network that contains a valid SSL certificate, causing the browser to display an "https" in the address bar.

Second, it uses homographic techniques to create a long URL that includes a series of fake slash marks in the address. (To prevent browsers from converting the characters to punycode, he had to obtain a domain-validated SSL wildcard cert for *.ijjk.cn).

"The diabolical thing is it looks like https://gmail.com," Marlinspike told The Register. "The problem is this bridge between http and https and that is a fundamental part of how SSL is deployed on the web. Changing that is not gong to be easy."

Marlinspike has successfully used the ruse on people using both the Firefox and Safari browsers. While he hasn't tested it on Internet Explorer, he assumes the technique works there too. And even if it doesn't, he says there's plenty of reason to believe even security-cautious users don't take the time to ensure their sessions are encrypted.

To prove his point, he ran SSLstrip on a server hosting a Tor anonymous browsing network (http://www.torproject.org/). During a 24-hour period, he harvested 254 passwords from users visiting sites including Yahoo, Gmail, Ticketmaster, PayPal, and LinkedIn. The users were fooled even though SSLstrip wasn't using the proxy feature that tricks them into believing they were at a secure site. Sadly, the Tor users entered passwords even though the addresses in their address bars didn't display the crucial "https." (Marlinspike said he later disposed of all personally identifiable information).

The attack is sure to touch off more head-scratching at places like Mozilla, Microsoft and VeriSign, where engineers have been wrestling with ways to make the SSL process more reliable. The easiest countermeasure is for users to type the entire https address into a browser (or better yet store it in a bookmark) so a tool like SSLstrip never gets a chance to alter a website's unencrypted link.

Additionally, although we've questioned the need for so-called extended validation SSL (http://www.theregister.co.uk/2008/05/16/paypal_page_succumbs_to_xss/) in the past, the new-fangled measure is one way to prevent users from being tricked by SSLstrip's proxy ruse.

EVSSL still won't protect users who don't take the time to look for an https in their browser's address bar each and every time they log in. And even if they did, many websites - take Wachovia's (http://wachovia.com/), for example - don't bother to display an https on login pages, so there would be no way for users at this site to know they were under attack until it was too late.

Marlinspike, who in 2002 demonstrated a separate https-busting tool called SSLSniff (http://www.theregister.co.uk/2002/08/16/ms_softpedals_ssl_hole/), said he sees no viable fix for the vulnerability, which he adds can be exploited in several additional ways he has yet to disclose.

"The ultimate solution," he said, "is to encrypt everything." ®


TOPICS: Computers/Internet
KEYWORDS: security; ssl

1 posted on 02/19/2009 10:25:04 AM PST by ShadowAce
[ Post Reply | Private Reply | View Replies]

To: rdb3; Calvinist_Dark_Lord; GodGunsandGuts; CyberCowboy777; Salo; Bobsat; JosephW; ...

2 posted on 02/19/2009 10:25:21 AM PST by ShadowAce (Linux -- The Ultimate Windows Service Pack)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ShadowAce

Ok, so it looks like the only defence on this is to have the customer type out https? It has to be encrypted right from the get go?


3 posted on 02/19/2009 10:56:31 AM PST by WakeUpAndVote (INGSOC starts 1.20.09)
[ Post Reply | Private Reply | To 2 | View Replies]

To: ShadowAce
As the old saying goes....

"Every time we make things more fool- hacker-proof, we get smarter fools hackers."

4 posted on 02/19/2009 11:18:32 AM PST by ken in texas (come fold with us - team #36120)
[ Post Reply | Private Reply | To 2 | View Replies]

To: WakeUpAndVote
Ok, so it looks like the only defence on this is to have the customer type out https? It has to be encrypted right from the get go?

It sure looks like it.

5 posted on 02/19/2009 11:35:44 AM PST by ShadowAce (Linux -- The Ultimate Windows Service Pack)
[ Post Reply | Private Reply | To 3 | View Replies]

To: ShadowAce

Do they have the C/I/P device or not??

That’s all I want to know.


6 posted on 02/19/2009 11:36:56 AM PST by BlueNgold (... Feed the tree!)
[ Post Reply | Private Reply | To 1 | View Replies]

To: BlueNgold

C/I/P device?


7 posted on 02/19/2009 11:43:24 AM PST by ShadowAce (Linux -- The Ultimate Windows Service Pack)
[ Post Reply | Private Reply | To 6 | View Replies]

To: ShadowAce

You clearly have not been watching the new season of 24...
Just a joke - someone out there got it I hope.


8 posted on 02/19/2009 11:45:55 AM PST by BlueNgold (... Feed the tree!)
[ Post Reply | Private Reply | To 7 | View Replies]

To: ShadowAce

Wondering on this. Customer does http://www.company.com, it hits the proxy and is redirected to the https version. In other words it comes in on 80, and comes back 443 without user intervention. Is that doing the same thing basicly or not?


9 posted on 02/19/2009 11:46:19 AM PST by WakeUpAndVote (INGSOC starts 1.20.09)
[ Post Reply | Private Reply | To 5 | View Replies]

To: BlueNgold

LOL—I gave up on 24 a few season ago when it just got to be too much to accept.


10 posted on 02/19/2009 11:50:03 AM PST by ShadowAce (Linux -- The Ultimate Windows Service Pack)
[ Post Reply | Private Reply | To 8 | View Replies]

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.

Free Republic
Browse · Search
General/Chat
Topics · Post Article

FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson