Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

lekkertech.net

Post reply on HN
Print view View original

41–50 of 79 posts

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

#41

Post by daeken »

makomk wrote: post #30
delsarto wrote: 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…

There's been a lot of overly-confident statements about Heartbleed not being a big deal from apparently competent people these last few days. I'm not sure what it is about it that causes security professionals to spout off without testing their assumptions, but...

When in doubt, always asssume a compromise of anything is a compromise of everything. Golden rule.

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

#42

Post by UnoriginalGuy »

polemic wrote: post #32
UnoriginalGuy wrote: post #21

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…

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

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

#43

Post by csoandy »

Willem, Thanks for the well-reasoned set of claims for us to evaluate. We are still looking at them, but a critical one is accurate: our own implementation of the secure memory area did not include the CRT values.

More here: https://blogs.akamai.com/2014/04/heartbleed-update-v3.html

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

#44

Post by paulhodge »

cscott wrote: post #37

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…

Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code. It would be easier for an expert to rewrite this patch from scratch than try to figure out all of their flaws and unfinished sections.

In one of the email responses, someone pointed out a problem with their code and they responded, "Oops we posted the wrong version" ( http://article.gmane.org/gmane.comp.encryption.openssl.user/... ). They aren't exactly being respectful of other people's time with stuff like that.

In secure coding the phrase "the devil is in the details" applies very strongly. So if you don't have the details figured out, you don't have much of anything.

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

#45

Post by binarycrusader »

tptacek wrote: post #18
StefanKarpinski wrote: post #3

Earlier quoted context omitted.

The tone of his post is rather unfortunate. Still, he raises good points, even if they are put in an unnecessarily aggressive manner.

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.

Empathy is a core engineering value. If not exercised, people will unsurprisingly often ignore what you have to say.

It's possible to be correct and helpful without saying unkind things.

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

#47

Post by tptacek »

rgbrenner wrote: post #24

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…

This would be a more compelling rebuttal to Willem's post if Akamai hadn't confirmed his central thesis:

https://blogs.akamai.com/2014/04/heartbleed-update-v3.html

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

#49

Post by gus_massa »

rocky_ee wrote: post #6
tptacek wrote: post #2

(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)

Pls elaborate

Tptacek has a software security company, and he is one of the unofficially designated security experts here (with cperciva). He is the #1 in the karma ranking and has even more karma that the site founder (pg)! If he says that “[Willem Pinckaers] knows what he's talking about”, for me it’s very strong reference for Willem Pinckaers.

Also, we generally don’t like oneliners here, try writing a longer comment. Definitively avoid Pls!!!! (And just in case, also try to avoid unoriginal jokes and memes.)

You are quite new here and your last 2 comments were heavily downvoted. I hope that someone upvote them until they are dark gray again. (The second comment, were you tried to explain your intentions, is not a bad comment.) [You’ve just deleted your second comment.]

Alternative redaction:

“I searched for Willem Pinckaers in Google and there is a lot of information about him. Can you recommend a few pages with his main projects to understand his background and credentials. Also, I’d love to know more about the projects in which you worked together in Matasano.”

[Note: perhaps the internal projects are under a NDA/top-secret/paranoid-client, and they can’t be explained until 2050.]

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

#50

Post by daeken »

tptacek wrote: post #47
rgbrenner wrote: post #24

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…

This would be a more compelling rebuttal to Willem's post if Akamai hadn't confirmed his central thesis: https://blogs.akamai.com/2014/04/heartbleed-update-v3.html

> As a result, we have begin the process of rotating all customer SSL keys/certificates.

AGHHHHHHH! Even if their code was likely to have worked perfectly, this is a huge mistake. And I mean huge. They should've operated under the assumption that their defense didn't work and immediately rotated all keys. Period.

Post reply on HN