Hacker News Reader

Comment by junto | Hacker News Reader

Every time I see a blog post from the Cloudflare team I am impressed.

It isn't just their attention to detail that is impressive. They go out of their way not just to point out issue, but suggest fixes.

Too many Heartbleed blog posts from across the blogosphere, and sadly, HN comments, set out to criticize without suggesting something better.

Cloudflare has shown again that they are actively engaging the community for the communities benefit as well as their own.

This seems to be a very effective marketing strategy (I assume it is anyway).

View on HN

I would have been more impressed had their original assessment of heartbleed (on nginx) not been "We've reviewed the code and we don't think it's vulnerable."

Looking impressive with hindsight is relatively easy.

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.

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.

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.

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'.

Reply on news.ycombinator.com