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.
> 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 my 15 minute security review, since it is so
overdue. (To be fair, I found the issue in minutes, but confirmation took
longer.)
Comes across quite passive aggressive indeed. The tone is otherwise fine, except that paragraph which is just one giant jab at Akamai.
I guess it is true what they say: No good deed goes unpunished. I'm sure Akamai has learned their lesson and will keep all future patches private to avoid public criticism and ridicule. But on the positive side at least we all know how smart Willem is, which I'm sure was the real point anyway.
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.
Speaking as a security researcher at Akamai, I can say that
tptacek is 100% correct here. We're absolutely better off for having received Willem's report, and I'm pretty sure we're all mature enough to tolerate the jabs that accompanied it.
I didn't have any part in writing this allocator, but I was asked to do a code review prior to publication. I told Rich Salz that it would take me at least two days to do a thorough one, and we both made the decision that it was better that we just get this code out there for public review and discussion than that we wait until we thought it was perfect.
So, with the caveat that we're still evaluating most of Willem's technical claims (and I'm probably going to be in the office all night doing so), the only sentence in Willem's report that I really take exception to is this one:
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.
This statement is self-refuting. If we hadn't published this
patch, we wouldn't be having this discussion, and some of the bugs that Willem and others are finding would have gone
unnoticed. I almost certainly would have caught the issue with the CRT intermediates if Willem hadn't done so first, but I doubt I'd have caught everything that has or will be identified through public scrutiny.
There's probably a middle ground here. If you'd taken the time to make sure the patch actually compiled, ran and attempted the things it was advertised to do before releasing it, I suspect problems with it would've been obvious sooner.
That's quite possible. It's also quite possible that we still wouldn't have released it yet, as we'd be doing that work to make it generally usable this week. Therefore, the critical failure - that we weren't protecting the CRT values - might not have been known yet.
Sadly, the multiverse doesn't yet let me monitor its A/B tests.
tptacek, we all want to hear Willem Pinckaers' take, it is really good stuff.
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"
I think there's a difference between sharing ideas and sharing code.
An idea or concept on its own can't really do much, at least until it's put into practice somehow. The potential for harm is quite minimal, if it even exists.
Code, on the other hand, can often be directly used with relative ease by people who may not fully understand the possible implications of using such code. The potential for harm exists, and could be significant.
In the context of security, it's important to avoid potentially-harmful code wherever possible. If somebody has concerns about some code, regardless of who wrote it, it is best to express those concerns in a very blunt and direct manner.
Security is just not something to fool around with. The hard questions and painful facts should be out in the open, especially when code is involved and capable of being used. It's just not the time or place for pussyfooting around.
Yup. Hard to read! Better that than not to read it.
As Rich Salz said in the post to openssl-dev, this is a prototype that nobody should take and use straight. We did think we were pretty lucky that our old patch to keep keys from being swapped to disk could help us against Heartbleed. A major voice in the internal decision about whether to release it or keep it secret as a "competitive advantage" was the possibility that we were wrong---in the hopes that someone would discover this and tell us if so. We were wrong. Pinckaers discovered this, and told us so.
He can mock my coffee as weak and my nose as big for all I care, in return for that necessary warning that we were mistaken.
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".
> Akamai strongly implied that their patch protected customers.
Actually they said exactly the opposite of that:
> This should really be considered more of a proof of
concept than something that you want to put directly into
production. Let me restate that: do not just take this
patch and put it into production without careful review.
Surely it's not passive aggressive when the author not only critiqued the code (an arguably "active" act of initiative), but offers to review the unpublished patch as well.
I don't find it aggressive, it seems more like Dutch directness to me. As an inhabitant of a neighbouring country, I must say it's an acquired taste ;)
The fact the code is badly written and wouldn't run isn't even the biggest problem with it though - a bigger issue is that the author didn't appear to realise there were copies of the key they'd missed that weren't protected. They very likely made the same mistake with their production systems and their analysis of those production systems.
