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.

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.

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.

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 :-).

How? I have some ideas but am interested to learn more. Do you have a reference for this?

This is just what you get when you have a Threatpost reporter interviewing a cryptographer. I think Brumley does a fine job answering the questions factually, without feeding the hype. There really is a timing attack to which most every implementation of OpenSSL is vulnerable.

The problem is that some people interpret that kind of as some kind of armageddon for internet security, whereas the great majority of secure systems probably aren't affected at all because they don't run the vulnerable code. But for those who are affected the problem may be really really serious for them. It is to these people that the researcher must communicate (via a journalist) without being able to select his audience in advance.

The problem isn't so much the degree to which the threat is or isn't real. If they wanted to fabricate unreal threats, they could certainly do a better

The problem is that there exists a truly massive security-industrial complex. For example, a huge percentage of the population within commuting distance of Washington DC have some kind of security clearance, and their employment depends on it, it's part of their social group, etc. Often these people have lived a relatively sheltered "whitebread" life, except for commonly military service in some place like Iraq. Their biggest worry is that they'll accidentally be friends with someone who'll be busted for pot and that will complicate up their security paperwork for the rest of their life. Sadly, these people are hard-pressed to understand America's freedoms, having renounced much of it for themselves.

Large, highly profitable industries have arisen to service this part of the Federal budget. So they hire people and more people to fill more and more funded positions with names like "Analyst". They write papers which sometimes come out like this.

Personally, I think this is one of the stupidest, most short-sighted, bits of analysis I've ever read. But it's important to contemplate how these things emerge from a process in which most or all of the people involved consider themselves to be doing the right thing for their country, career, employer, social circuit, etc..

It's not FUD and it's not "the sky is falling" either.

This is cryptographers communicating with one another. Terms like "attack" are being used here in their academic meaning. It's an interesting result, exciting even, but shouldn't be emotionally charged.

If there are any real systems at risk, I don't know of them. But it's certainly possible that someone somewhere is really screwed by this attack, so it should be taken seriously. Anyone using ECDSA should probably apply the forthcoming patches as soon as is practical. This is good advice in any case.