Slashdot Mirror
SSL/TLS Vulnerability Widely Unpatched
kaiengert writes "In November 2009 a Man-In-the-Middle vulnerability for SSL/TLS/https was made public (CVE-2009-3555), and shortly afterwards demonstrated to be exploitable. In February 2010 researchers published RFC 5746, which described how servers and clients can be made immune. Software that implements the TLS protocol enhancements became available shortly afterwards. Most modern web browsers are patched, but the solution requires that both browser developers and website operators take action. Unfortunately, 16 months later, many major websites, including several ones that deal with real world transactions of goods and money, still haven't upgraded their systems. Even worse, for a big portion of those sites it can be shown that their operators failed to apply the essential configuration hotfix. Here is an exemplary list of patched and unpatched sites, along with more background information. The patched sites demonstrate that patching is indeed possible."
I recall that firefox detects this, so using firefox + firebug and checking the console might tell you if a site is vulnerable.
Hey don't blame me, IANAB
Unfortunately, 16 months later, many major websites, including several ones that deal with real world transactions of goods and money, still haven't upgraded their systems. Even worse, for a big portion of those sites it can be shown that their operators failed to apply the essential configuration hotfix.
Lately we've also been finding out that many major websites are storing passwords as plain text and are untested against SQL injection. So it's unsurprising that they're also unpatched.
Web servers need to be actively watched, maintained and scanned for vulnerabilities. Just because it's a LAMP server doesn't mean it's rock-solid. The fire-and-forget philosophy does not apply.
/* No Comment */
I like Qualys' SSL Labs
I spent a few minutes looking for the same thing, and found that Firefox includes a check. If you visit an HTTPS site that is not secure, you will get a message in the Error Console under Messages saying something like this:
site.example.com : server does not support RFC 5746, see CVE-2009-3555
For more information, see https://wiki.mozilla.org/Security:Renegotiation
After reading this article I ran a quick audit on all of our server farms and noticed that KB980436 was dutifully installed Sept 2010...however, upon closer scrutiny I noticed that this Security Patch from Microsoft doesn't prevent this vulnerability by default (but rather keeps it in "Compatibility Mode" by default). Windows SysAdmins need to take care to read MS10-049 and add the appropriate RegKeys to enforce "Strict Mode" to keep their servers from being vulnerable to this exploit. FYI, downloading and installing KB980436 is not enough.
Interesting question. I guess you could argue that a theoretical shortcoming isn't a vulnerability if there's no practical exploit.
But that ignores the temporal part of it. It is only not a vulnerability, because it's not practically exploitable right now. Things change, technology changes, new avenues for attacking the shortcoming open up.
It's like the recent proven exploit we saw a few days ago on a quantum message transfer. The method had been theorized, but never been shown. Now that it's been shown, it can be taken more seriously.
I vote based on politicians' actions, unless contrary to my preconceptions. Often wrong, never uncertain. #iamthe99%
Depends on your definition of "vulnerability". For example, there's a vulnerability in AES's key schedule that weakens the 256 and 192 bit versions down to roughly 99.5 bits security. However, this is not an exploitable vulnerability, as the stars will still have all gone cold and dark by that time.
upon the advice of my lawyer, i have no sig at this time
I mentioned Qualys' SSL Labs nice test utility in another comment.
The fix is to ask your vendor for a patch for CVE-2009-3555 which implements RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. Responsible vendors will have implemented support for RFC 5746 by now so you may already be patched.
Last week my Father sent me the debug output of a NoScript dump where Abe detected potential XSS while he was connecting to Wells Fargo Online Banking - the XSS was bogus but among the other messages was this disheartening line printed over and over again:
www.wellsfargo.com : server does not support RFC 5746, see CVE-2009-3555
Almost as lame as Citi's CC numbers in the URL string.
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
According to the page in question, the test methodology is:
1. Connect with RFC 5746. Upon success, mark as "Good".
2. If the connection fails, the site is not patched. Send a request "HEAD / HTTP/1.1" without using RFC 5746, and save the response for later comparison.
3. Run the actual test. This basically does the following:
If a site has been updated with a partial hotfix, it should either disconnect or sent an HTTP status code in the 400s. These sites are flagged as "Uncertain" because the server might initiate a renegotiation. If the site sends data after the second handshake and the response code is the same as the response code from step #2, it is marked as BAD.
Discuss.
Check out my sci-fi/humor trilogy at PatriotsBooks.