SSL/TLS Vulnerability Widely Unpatched 103
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."
Re:Unexploitable vuln? (Score:3, Interesting)
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.
Re:A warning against banner-grabbing vuln scans (Score:4, Interesting)
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.