I have been assured by a very knowing American of my acquaintance in London, that a young healthy child well nursed, is, at a year old, a most delicious nourishing and wholesome food, whether stewed, roasted, baked, or boiled; and I make no doubt that it will equally serve in a fricasie, or a ragoust.
This is not a bug. We fixed renegotiation with the RFC 5746 RI extension! That said, SSL has long been known to impose more work on the server than on the client and renegotiations are no different than initial handshakes in this respect.
Servers that accept client-initiated renegotiation make things slightly more efficient for the DoS attacker, it saves him maybe three packets. More significantly, it may bypass mitigations that are only looking for TCP SYN packets. But the attacker's mileage will vary.
There was this popular movie "The China Syndrome" with Jane Fonda about a news crew that just happened to be in the right place at the right time to film a nuclear plant accident from the control room. The company tried to cover it up and the good guys got all activist and stuff. http://en.wikipedia.org/wiki/The_China_Syndrome
There was this really weird coincidence where there was an accident at a real nuclear plant (Three Mile Island) at the same time the film was running.
Yes, the overall security research community has greatly benefited from some of these large password database disclosures. We've learned a lot about password handling practices both on the back-end (unsalted MD5, or bcrypt?) and users (password crackability). In fact, there has been some overlap in the user base of the breached sites that we can start to look at things like how common password re-use is across multiple sites.
For the record, Microsoft pushed out (via Windows Update) a patch fully implementing the fix for this well before many other vendors (including some popular Linux distros) did, even though their server (IIS) wasn't nearly as vulnerable in its default configuration as Apache+OpenSSL.
It may be that 2^100 computation will never be practical for any plausible attacker, but it's not the truly cosmic level of work you make it out to be.
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.
I'd published packet captures of the exploit in action as part of the initial disclosure. Someone else had working exploit code posted to [Full-Disclosure] within hours.
The blind plaintext injection capability that an exploit gives to the attacker was uncommon at the time and the initial reaction among experts was that it looked a lot like a CSRF attack. Most important sites had built in some protections against that.
It wasn't until a few days later when it was demonstrated against a social networking site (Twitter) that the problem was declared "real" (by Slashdot).
So it's a complex exploit and it did take a few days for a consensus to emerge about the actual severity.
Email them and ask why they haven't applied the fix for CVE-2009-3555!
Note that "not supporting secure renegotiation" doesn't necessarily mean that the site itself is insecure, it means that the browser is unable to determine if it is or not. The degree to which this is a meaningful distinction is a really interesting discussion.
But it does suggest that they have a really clueless vendor or they haven't applied security patches in a long time.
In 2008, Stevens, Sotirov et al. proved that you could, in fact, pwn PKI with just a collision. It doesn't take a full preimage. http://www.win.tue.nl/hashclash/rogue-ca/
Remember, usually all you have to do is confuse the SSL client. There's usually little that can be gained by agonizing over the crypto parameters of the legitimate server cert, because the attacker gets to choose the weakest thing that the client will accept.
I do not know if I weaken my security by prefixing the hash with something like "{SSHA256}", but I am not one to rely on obscurity for security.
Just prepending a fixed string to the input or output does not weaken the hash algorithm. In fact, you should include as much contextual information as is practical into the information being authenticated. The NIST SHA-3 candidate Skein, for example, has defined inputs for exactly such custom "tweaks" to the function. NIST defines truncated versions of SHA-256 and SHA-512 where all they do is change the initialization vector so the functions aren't accidentally compatible.
But watch out, where it might weaken the security is if your system later reads that value and uses it in the interpretation of the hash. For example, what if I fed you "{SMD5}aa64fc8e163669ba598fb3fff8c57741", would your system then degrade to the security of MD5 instead?
MD5 isn't bad, for example, as part of the "stirring" function for the entropy pool in a pseudo random number generator. I believe it's used this way in the design of several open-source kernels. Possibly OpenSSL too, but my memory's not as sure about that one.
But, yeah, even in cases where it might still be useful you probably don't want to use it. It's likely to trigger a lot of unnecessary discussion about it being broken (unless that's your goal of course:-).
For example, do you know whether the random salt should be appended or prepended to the hashed data? One of those two options can result in an insecure hash.
How? I have some ideas but am interested to learn more. Do you have a reference for this?
Slashdot Mirror
That's hilarious...as if RDTSC would be difficult to figure out what it did.
But at least the attacker's data is secure in transit.
...where you're a guy with a knife or a gun and you run around killing things and making blood splatter.
Of course, this solution has been proposed before:
I have been assured by a very knowing American of my acquaintance in London, that a young healthy child well nursed, is, at a year old, a most delicious nourishing and wholesome food, whether stewed, roasted, baked, or boiled; and I make no doubt that it will equally serve in a fricasie, or a ragoust.
It's a real attack and a real DoS vector. SSL/TLS is definitely weak in this regard.
But it's not new and it doesn't have much to do with renegotiation.
This is not a bug. We fixed renegotiation with the RFC 5746 RI extension! That said, SSL has long been known to impose more work on the server than on the client and renegotiations are no different than initial handshakes in this respect.
Servers that accept client-initiated renegotiation make things slightly more efficient for the DoS attacker, it saves him maybe three packets. More significantly, it may bypass mitigations that are only looking for TCP SYN packets. But the attacker's mileage will vary.
Eric Rescorla (SSL/TLS RFC author) has a good blog post about the issue. http://www.educatedguesswork.org/2011/10/ssltls_and_computational_dos.html
Even if Geohot had lost the lawsuit it wouldn't make him a criminal. This article submission stinks and I'm ashamed of Slashdot for posting it.
There was this popular movie "The China Syndrome" with Jane Fonda about a news crew that just happened to be in the right place at the right time to film a nuclear plant accident from the control room. The company tried to cover it up and the good guys got all activist and stuff. http://en.wikipedia.org/wiki/The_China_Syndrome
There was this really weird coincidence where there was an accident at a real nuclear plant (Three Mile Island) at the same time the film was running.
Yes, the overall security research community has greatly benefited from some of these large password database disclosures. We've learned a lot about password handling practices both on the back-end (unsalted MD5, or bcrypt?) and users (password crackability). In fact, there has been some overlap in the user base of the breached sites that we can start to look at things like how common password re-use is across multiple sites.
For the record, Microsoft pushed out (via Windows Update) a patch fully implementing the fix for this well before many other vendors (including some popular Linux distros) did, even though their server (IIS) wasn't nearly as vulnerable in its default configuration as Apache+OpenSSL.
Perhaps, but who's going to pay for the development of the first exploit? The attacker or the defender?
It may be that 2^100 computation will never be practical for any plausible attacker, but it's not the truly cosmic level of work you make it out to be.
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.
I'd published packet captures of the exploit in action as part of the initial disclosure. Someone else had working exploit code posted to [Full-Disclosure] within hours.
The blind plaintext injection capability that an exploit gives to the attacker was uncommon at the time and the initial reaction among experts was that it looked a lot like a CSRF attack. Most important sites had built in some protections against that.
It wasn't until a few days later when it was demonstrated against a social networking site (Twitter) that the problem was declared "real" (by Slashdot).
So it's a complex exploit and it did take a few days for a consensus to emerge about the actual severity.
Email them and ask why they haven't applied the fix for CVE-2009-3555!
Note that "not supporting secure renegotiation" doesn't necessarily mean that the site itself is insecure, it means that the browser is unable to determine if it is or not. The degree to which this is a meaningful distinction is a really interesting discussion.
But it does suggest that they have a really clueless vendor or they haven't applied security patches in a long time.
I like Qualys' SSL Labs
Millions of guesses per second is pretty common for modern GPUs.
Remember, usually all you have to do is confuse the SSL client. There's usually little that can be gained by agonizing over the crypto parameters of the legitimate server cert, because the attacker gets to choose the weakest thing that the client will accept.
It's still essentially a web of trust. You trust Verisign, Thawte, the DPRK, and all kinds of others, and they trust whomever they trust.
Except that they don't trust anybody. Which makes it very un-web-like.
In computer sciencey lingo, PKI is a set of short trees rather than a general directed graph.
I do not know if I weaken my security by prefixing the hash with something like "{SSHA256}", but I am not one to rely on obscurity for security.
Just prepending a fixed string to the input or output does not weaken the hash algorithm. In fact, you should include as much contextual information as is practical into the information being authenticated. The NIST SHA-3 candidate Skein, for example, has defined inputs for exactly such custom "tweaks" to the function. NIST defines truncated versions of SHA-256 and SHA-512 where all they do is change the initialization vector so the functions aren't accidentally compatible.
But watch out, where it might weaken the security is if your system later reads that value and uses it in the interpretation of the hash. For example, what if I fed you "{SMD5}aa64fc8e163669ba598fb3fff8c57741", would your system then degrade to the security of MD5 instead?
By asking Slashdot?
There is no reason to use MD5 anymore.
MD5 isn't bad, for example, as part of the "stirring" function for the entropy pool in a pseudo random number generator. I believe it's used this way in the design of several open-source kernels. Possibly OpenSSL too, but my memory's not as sure about that one. But, yeah, even in cases where it might still be useful you probably don't want to use it. It's likely to trigger a lot of unnecessary discussion about it being broken (unless that's your goal of course :-).
For example, do you know whether the random salt should be appended or prepended to the hashed data? One of those two options can result in an insecure hash.
How? I have some ideas but am interested to learn more. Do you have a reference for this?