31–40 of 79 posts
Earlier quoted context omitted.
I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.
This: > Perhaps Akamai is not actually running this version in production, but another 'super secure' allocator. In either case they should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack. Andy Ellis, CSO of Akamai, said on Twitter that the 'secure' allocator was written 13 years ago. I'm happy to provide the results of…
Oh so what. Tone arguments are the least interesting arguments (he says, passive aggressively). In seriousness though, this is a blunt assessment from an expert in the field. The tone is entirely appropriate.
> No good deed goes unpunished.
Akamai strongly implied that their patch protected customers. If you make that claim then you need to be prepared to have the claim attacked. This is an issue of good will toward their customers - not to the Open Source community.
This isn't a case of "punishing a good deed", it's a case of "critically examining a provider's claim to their customers".
Earlier quoted context omitted.
How would a less-aggressive tone be better at delivering the necessary info to Akamai and its customers?
[deleted]
(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)
I've updated my blog on how to recover the private key from the CRT parameters stored in the private key: http://vnhacker.blogspot.com/2014/04/idea-to-solve-cloudflar.... Trivial math, but still interesting to see how it actually works.
A review by a security engineer would have prevented a false sense of security Everyone involved in this, from the people who wrote the heartbeat code, the people who committed the code, the people at Akami who wrote this patch, this poster ... all would describe themselves as security engineers. Is everyone but Willem Pinckars incompetent? I think the one lesson to learn is to treat crypto just like you do cloud pro…
Which of the assertions in the post do you disagree with?
1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch.
2. On the other hand, if they are supplying this code as assurance that customer keys were properly protected against exposure by the Heartbleed bug and that certificate replacement is not needed, the patch and the subsequent criticism should give Akamai customers pause.
edit: Akamai acknowledges the bug, and has started rotating all customer SSL keys/certificates, per https://blogs.akamai.com/2014/04/heartbleed-update-v3.html
It comes down to intent. There are two distinct ways to evaluate Akamai's patch: 1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch. 2. On the other hand, if…
If this code was running on the Akamai networks for years, why did they have a copy laying around that didn't call mprotect? Given the above problems I wonder how Akamai manages to run this in production. How could you misread a two paragraph email so badly. Here, let me shorten it up for you: This patch is a _variant_ of what we've been using to help protect customer keys for a decade. This should really be consider…
It's more an 'exemplar of concept' or something, really - which is still valuable, but I do wish they'd made that more clear.
Earlier quoted context omitted.
This: > Perhaps Akamai is not actually running this version in production, but another 'super secure' allocator. In either case they should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack. Andy Ellis, CSO of Akamai, said on Twitter that the 'secure' allocator was written 13 years ago. I'm happy to provide the results of…
This post isn't simply "ridiculing" the proposed allocator design. Did you work on this allocator? If not, can I suggest that you be a little careful? It's one thing to stick up for Akamai's developers; it's another to be thin-skinned on their behalf. It's possible that Akamai's devs, being adults, professionals, and engaged with software security, actually want to hear Willem Pinckaers' take on their allocator.
I also want to hear ideas from Akamai, even if they aren't perfect. Perhaps they can lead to good things.
Unfortunately Pinckaers' commentary is a little bit too hostile and calls for Akamai to cease sharing ideas[1].
I'm sure Akamai's developers are "adult" enough, as you say, to handle it. However there is a trope in software development community that if you share something, you should be fine with being open to no holds barred attacks. Wouldn't the more "adult" behavior be to criticize in a more professional tone that is open to refinement of ideas and could spark further collaboration? I'd like to see this type of communication more in the software world, I think it would encourage more participation.
[1]"they should not be sending out non-functional, bug ridden patches to the OpenSSL community"