Live data from Hacker News

Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

lekkertech.net

71–79 of 79 posts

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#71
post #19

Earlier quoted context omitted.

Which of the assertions in the post do you disagree with?

I think it's reasonable to disagree with the part he quoted. "A review by a security engineer ..." Well, it was reviewed by security engineers, and the false sense of security remained. The rest seems fine though.

My experience in large companies is more like this: A (security) engineer reviews, objects and management says: "Go ahead anyway you don't have the whole picture".

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#72
post #32

Earlier quoted context omitted.

> Comes across quite passive aggressive indeed. 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 clai…

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

I think polemic was referencing this statement[1] when he talks about "their patch" (and not the released patch):-

> This patch is a variant of what we've been using to help protect customer keys for a decade.

1. From the original Akamai missive: http://article.gmane.org/gmane.comp.encryption.openssl.user/...

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#73
post #61
post #28

Earlier quoted context omitted.

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 thorou…

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.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#76
post #9

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…

I don't think I've worked anywhere where there was a simple way to switch cloud providers with the push of a button. Even migrating to different locations within a cloud provider isn't trivial. You'd have to invest a lot of engineering time from the beginning to get this kind of capability, and you may never realize any value for all the pain.

in my team we had the scripts ready for a second provider (but not the hot backups, I couldn't get that far).

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#77
post #67
post #65

Earlier quoted context omitted.

Nope. As long as they don't distribute it but only run it in a server, they don't have to. This is what the AGPL is changing.

Not here: you can't do much with AGPL+OpenSSL. AGPL requires release under AGPL. OpenSSL requires advertising clause. There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.

> There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.

If you modified AGPL code you have to release it. If you've mixed up GPL or AGPL code such that you can't release it you've violated the license for the hard work of others. You sound confused, to phrase it charitably.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#78
post #67

Earlier quoted context omitted.

Not here: you can't do much with AGPL+OpenSSL. AGPL requires release under AGPL. OpenSSL requires advertising clause. There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.

> There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license. If you modified AGPL code you have to release it. If you've mixed up GPL or AGPL code such that you can't release it you've violated the license for the hard work of others. You sound confused, to phrase it charitably.

My interpretation of what he wrote is that it does not change things for them in the sense that due to conflicting licenses, they can't use AGPL'd software, and so the AGPL changes nothing.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#79
post #73
post #61

Earlier quoted context omitted.

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 thorou…

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.

Post reply on HN