What is Digg?Sponsored by newegg
Missed out on the best electronic deals last Black Friday? view!
newegg.com - Newegg.com's Cyber Monday Promotion has you covered. No Lines, No Crowds; Just Click and Save.
22 Comments
- wassamatta, on 11/08/2009, -0/+31No mention of the flaw in the article. Don't bother reading it.
- gasoline, on 11/08/2009, -2/+28There is no bug in SSL: http://www.imperialviolet.org/2009/11/05/tls-reneg ...
"Here's the issue: there's an extremely uncommon configuration of web servers where they're setup to require client side certificates for some URLs and not others. If a user has an HTTPS connection open that didn't handshake with a client side certificate and they try to access such a URL, the webserver will perform another handshake on the same connection. As soon as that handshake completes with the correct certificate, they'll run the request that was received from before the connection was fully authenticated.
It's a bug in the web server. There was a misunderstanding between what the folks writing the webserver thought that TLS was providing and what it actually provides. One might also argue that it's a short coming in the HTTP protocol (there's no way for a server to ask a client to redo a request). One might also argue that TLS should provide the properties that the web servers expected.
But it's not a flaw in TLS. The TLS security properties are exactly what was intended." - op12, on 11/08/2009, -0/+12There's a lot more details about the flaw in the source PCWorld article, which I submitted here:
http://digg.com/security/Vendors_Scrambling_to_Fix ...
(ignore the messed up title) - ITSpecific, on 11/08/2009, -2/+12Should have informed the vedors before releaseing the information to the public, but eh, whatever.
- rusty0101, on 11/08/2009, -1/+9Not to disagree, but which vendors? SSL is an open standard used by a wide variety of applications, not just web browsers. There are vpn's that rely on it for example. Should the person who found the flaw have limited notification to a few companies that write web browsers, or should he have made an effort to hunt down each and every product that embeds SSL or links to the libraries to make sure that they know?
The details in the article are a bit light in that it states that the person who found the flaw after the initial developers were working on resolving it 'posted details' without any indication of whether the 'details' included a theoretical explanation of how to make use of the flaw, beyond later stating that there are not any exploits known yet.
It also sounds like he wanted to work on fixing the problem rather than exploiting it, or encouraging others to exploit the flaw. - rusty0101, on 11/08/2009, -1/+7or is it the ISL protocol?
- kafka47, on 11/08/2009, -0/+5I work for RSA EMC. Sorry, I wish it were otherwise but this attack has been demonstrated without using client authentication in the TLS connection.This affects IIS and Apache and will be fixed.
Marsh Ray's blog (publicist of the vulnerability) :
http://extendedsubset.com/?p=8
"In particular, practical attacks against HTTPS client certificate authentication have been demonstrated against recent versions of both Microsoft IIS and Apache httpd on a variety of platforms and in conjunction with a variety of client applications. Cases not involving client certificates have been demonstrated as well..."
Original whitepaper : http://www.g-sec.lu/Renegotiating%20TLS.pdf
MITM attacks *are* extremely rare. But this will definitely be fixed across the board. - Kral, on 11/08/2009, -1/+5So it's just an issue with client side certificates? That's probably like 0.00001% of SSL traffic. Most people don't even know that feature exists.
- oboshoe, on 11/08/2009, -0/+4cloak and dagger? - lol
This is the standard way the software companys fix security defects. They fix, THEN tell. They don't tell then fix.
Some folks disagree with that approach and thats ok. But's the standard approach used by all software vendors. Nothing cloak and dagger about it. - peteyb1313, on 11/08/2009, -0/+3Are you talking about the null character (\0) flaw? If so, no it doesnt seem it is.
- unic0rn, on 11/08/2009, -1/+4Either I read the article wrong, or you did.
The "Internet Consortium" or whatnot has been working on fixing the flaw for a while now, but stealthily. Sort of like Dan Kaminsky's DNS flaw.
Someone found this SSL flaw, thought releasing it was the right thing to do, and now since it's out in the open, the Consortium revealed it's plans of also fixing the hole. - khimairaGT, on 11/08/2009, -1/+3is this the same flaw that was talked about at defcon?
- rushover, on 11/08/2009, -2/+4Being even remotely surprised about SSL security flaws is so 2 years ago.
- golgotha, on 11/08/2009, -0/+2"Although an attacker would first need to hack into the victim's network to launch the man-in-the-middle attack".....
that's all I need to know. Next. - CmdrObvious, on 11/08/2009, -0/+2WebServer != WebBrowser
Just to clear things up - op12, on 11/08/2009, -0/+2I got the title corrected, but that made the previous URL invalid. I wish Digg would make it easier to edit submissions!
The article is here now:
http://digg.com/security/Vendors_Scrambling_to_Fix ... - YZBot, on 11/08/2009, -4/+5I guess I will call it the USL protocol until it's fixed then.
- CmdrObvious, on 11/08/2009, -0/+1No, I think this flaw has more to do with two protocols not quite coming together properly, more of a design flaw than anything else. The potential for a 'useful' exploit seems rather low to me, but that isn't saying too much :)
- KibibyteBrain, on 11/08/2009, -1/+1That's much like saying if a locksmith finds a new way to pick a standard type of lock, he should contact any company who could possibly make locks in the WORLD and ensure they set up programs to upgrade all installed locks first before publishing his findings, but somehow ensure it is held to secrecy among non-malicious parities in that process. About similar in realism.
- BeesKnees21, on 11/08/2009, -0/+0Cool. I didn't understand any of that but all the acronyms made it sound convincing.
- burrdugg, on 11/08/2009, -2/+2No need to contact every single vendors individually. Only contact the devs for the flawed software.
Or if the flaw is in a specific implementation like OpenSSL, or JSSE, or other proprietary counterparts, then contact those only. Not every software using SSL is going to be affected. Each software devs concerned will get the get fix from there. You don't need to hunt for every possible vendors in that case.
If the flaw is in the SSL protocol itself, then the whole industry is truly *****, contact the authors to fix it http://tools.ietf.org/html/rfc5246, or dump SSL althogether for a safer protocol. - Princeamor, on 11/08/2009, -10/+2Why make it public info? Just tell Mozilla, Apple and Microsoft and THEN tell the people that you fixed it!
© Digg Inc. 2009
— Content created and posted by Digg users is