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.

>> what is the MAFIAA going get?
Why, the Irish people, of course.

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.

He was impressed with the market principals, too:

Lots of guys now order from a couple big shops

I remember the 70's as a little kid.

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.