Hacker News Reader

Comment by jgrahamc | Hacker News Reader

The original blog post on Heartbleed said: "Here’s the good news: after extensive testing on our software stack, we have been unable to successfully use Heartbleed on a vulnerable server to retrieve any private key data. Note that is not the same as saying it is impossible to use Heartbleed to get private keys. We do not yet feel comfortable saying that."

In that same blog post we also said that we were revoking and reissuing all our SSL keys, and started the challenge web site to see if private keys could be retrieved.

http://blog.cloudflare.com/answering-the-critical-question-c...

So, yeah, we didn't from the outset figure out how to get the private keys, but we decided that the risk was too high so we want ahead with revocation.

View on HN

Argh. That's spin. The Cloudflare post you are talking about was written so convincingly that Bruce Schneier summed it up as "Cloudflare believes it is next to impossible that this vulnerability will leak keys".

You have to consider the whole post, which led off with why Cloudflare believed keys wouldn't leak, then went on with a 1000+ word description of how malloc() worked, complete with diagrams, and then concluded with a belief the keys wouldn't leak.

If, instead of running "The Cloudflare Challenge", Cloudflare had simply had you generate the memory diagrams that you built last week, it would have been a different post and less of a waste of everyone's time.

Hindsight. Nobody had the technology for the allocation diagrams then, they were encouraged to implement them only once people presented them the fetched keys.

The results of the challenge were a good learning possibility for a lot of people and we, the observers, have now also something we can point to as an example.

I dispute that it requires hindsight to believe, with some certainty, that OpenSSL was going to leak keys all over the heap; especially because (a) people were immediately pointing out that that was likely to be the case, along with potential scenarios where it could happen, and (b) people were posting to Twitter that they had working proofs of concept.

Doing any challenge to demonstrate key recovery might have been a sound plan, but the specific challenge that Cloudflare promoted was one that pessimized the discovery function of the challenge and optimized the the reinforcement of their false prediction; to wit, they tied people's hands behind their back, forcing them to attack a remote instance of a process with an unsure memory layout.

Yes, I agree that the challenge was more challenging than needed. Still now we have even better example of how wrong is to believe you solved the security problem unless there is some active attempt to disprove the claimed solution. Cloudflare were lucky to have that crowd-sourced this time. But it's still a great example of how wrong the claims "we solved the security problems" can be.

No! Do not agree! There's a different simple maxim that would have worked here just fine: assume the worst. If you're going to heavily promote something other than "assume the worst", the onus should be on you to make sure you're right!

I don't think it's unfair to paraphrase this statement:-

"And, we have reason to believe based on the data structures used by OpenSSL and the modified version of NGINX that we use, that it may in fact be impossible."

"We've reviewed the code and we don't think it's vulnerable."

Obviously you disagree.

Context is important when you see that many weasel words. "We do not yet feel comfortable saying that." Means there still undecided as does 'may' in 'may be impossible'.

Yeap, when I read the original statement it really seemed to be telling the customers there was nothing to worry about, and I think that's how it was meant to be read.

When the original statement was posted I actually went back to the header to check the author, thinking "surely jgc wouldn't post something this marketroid?"

Only in hindsight do they point at the get-out clauses.

Reply on news.ycombinator.com