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

Heartbleed Update v3

blogs.akamai.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Heartbleed Update v3

#41

Post by Narkov »

daeken wrote: post #32
Narkov wrote: post #29

Earlier quoted context omitted.

They believed that they were covered and that no compromise could/did occur. It's a mistake they now acknowledge but they have owned up to it and are taking action - just as you suggest. I believe their actions are honest and completely reasonable. If they had known they still had an issue I seriously doubt they would have publicised the patch and risk the issue they now have.

> I believe their actions are honest and completely reasonable. If they had known they still had an issue I seriously doubt they would have publicised the patch and risk the issue they now have. I completely agree that their actions are honest, and I seriously doubt they would have played things this way if they knew their protections were faulty. I'm not saying that they're acting maliciously; I'm saying that they a…

> If an attacker can read memory out of a process containing sensitive data, the assumption should always be that they got the keys to the kingdom even if they didn't

We both agree on this.

> but that they played chicken with an exploit and ended up on the wrong side of it.

I disagree with this. They thought they had a valid technical solution and did the honourable thing by releasing it. Unfortunately they were wrong but that's a bug and not a arrogance issue.

Re: Heartbleed Update v3

#42

Post by wdr1 »

Interesting to note that if Akamai hadn't open sourced their modifications, they never would have realized their certs actually had been compromised.

Re: Heartbleed Update v3

#43

Post by joeybaker »

This is the perfect example to point people to when they ask why the company shouldn't just maintain an internal fork or write its own version of an open source project.

Actually contributing the code you write is helps _everyone_.

Re: Heartbleed Update v3

#44

Post by tptacek »

Sami_Lehtinen wrote: post #20

Why people are only talking about SSL keys? Because Heartbleed allowed to fetch any data, that could have also included SSH keys and or any other authentication credentials / information the server got, for itself or to other services. As example if your site got Facebook API keys it's possible that those have been leaking too.

No, your web server process memory does not include SSH keys.

Re: Heartbleed Update v3

#45

Post by madaxe_again »

glimcat wrote: post #6
Artemis2 wrote: post #3

Good politics: they had custom code for parts of OpenSSL, they published it when it seemed needed, open-source community told them what was wrong, they fixed it and apologized. No bullshit.

Also: the way this played out makes an awesome story for the next time Akamai experiences internal pushback against participating in open source. "Remember that one time it saved our bacon" is a political goldmine.

Nope. People will remember it as "remember all that work as a result of OpenSSL?"

Re: Heartbleed Update v3

#46

Post by roel_v »

glimcat wrote: post #6
Artemis2 wrote: post #3

Good politics: they had custom code for parts of OpenSSL, they published it when it seemed needed, open-source community told them what was wrong, they fixed it and apologized. No bullshit.

Also: the way this played out makes an awesome story for the next time Akamai experiences internal pushback against participating in open source. "Remember that one time it saved our bacon" is a political goldmine.

Look, I like open source as much as the next guy, but this is myopic - one might as well say 'remember that one time we used open source stuff and we had to spend weeks scrambling to fix things?'. Please let's not fool ourselves into believing things that simply aren't true - it detracts from the things we can leverage.

Re: Heartbleed Update v3

#47

Post by makomk »

blahedo wrote: post #27
daeken wrote: post #18

Earlier quoted context omitted.

No, this was not a good response. It was well written and took responsibility for bad code, but it failed to address the elephant in the room: why were keys not immediately rotated? I've said this a number of times lately, but it bears repeating that the golden rule of security is: If a compromise occurs, assume that everything is compromised. Even if their approach was tested to be perfect, they shouldn't have made…

No, that goes too far the other way. If I have legitimate reason to believe that an exploit does not affect me (especially if it's because I acknowledged its possibility and programmed defensively against it), why would I automatically act as if I were breached too? Your argument is totally correct if I am simply unsure---if I don't know whether an exploit affects me but I suspect it might, I assume the worst and act…

Take a look at how much protection people's legitimate reasons to believe that this didn't affect them have given so far - the only people who haven't been proven wrong were the ones who weren't running a vulnerable OpenSSL. Their arguments all assumed that because they couldn't imagine a way to get the keys there wasn't one, when in fact they just hadn't thought about it enough.

Re: Heartbleed Update v3

#48

Post by Serow225 »

kevinr wrote: post #37
sweettea wrote: post #14

Earlier quoted context omitted.

I suspect their patches are oriented toward paranoia. Their particular patch (keeping what they believed to be all critical values in a special region of memory used only for critical things) had no obvious necessity -- it didn't obviously provide more security -- but was just paranoia. Paranoia isn't always necessary, or even desirable; hence, the remainder of the patches have no obvious external utility, so they pr…

As Andy tweeted, we built that particular patch to keep unencrypted secrets off disk -- it actually was intended to provide tangible security benefit, it wasn't just paranoia: https://twitter.com/csoandy/status/455307255895060480

If you folks have used this technique for years as I believe it has been stated, any particular reason why it wasn't contributed back to OpenSSL earlier?

Re: Heartbleed Update v3

#49

Post by grayclhn »

blahedo wrote: post #27
daeken wrote: post #18

Earlier quoted context omitted.

No, this was not a good response. It was well written and took responsibility for bad code, but it failed to address the elephant in the room: why were keys not immediately rotated? I've said this a number of times lately, but it bears repeating that the golden rule of security is: If a compromise occurs, assume that everything is compromised. Even if their approach was tested to be perfect, they shouldn't have made…

No, that goes too far the other way. If I have legitimate reason to believe that an exploit does not affect me (especially if it's because I acknowledged its possibility and programmed defensively against it), why would I automatically act as if I were breached too? Your argument is totally correct if I am simply unsure---if I don't know whether an exploit affects me but I suspect it might, I assume the worst and act…

> If I have legitimate reason to believe that an exploit does not affect me (especially if it's because I acknowledged its possibility and programmed defensively against it), why would I automatically act as if I were breached too?

Your argument hinges on the word "legitimate." I don't do security, but "it looks good to me" is not a legitimate reason to believe that the exploit does not affect you (for any value of "me"). OTOH "I've never used the versions of OpenSSL that have this bug" is a legitimate reason to believe that you're not affected, e.g. Tarsnap's explanation [1]. I'd also recommend that post for another take on what defensive programming looks like in this context.

[1] http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartb...

on HN: https://news.ycombinator.com/item?id=7562125

Re: Heartbleed Update v3

#50

Post by jonhohle »

chubot wrote: post #13

What's interesting is that I just watched a video that strongly relates to this problem last night (from DJB at CCC): https://www.youtube.com/watch?v=IuSnY_O8DqQ http://facthacks.cr.yp.to/ It is only part of the video, but they talk about searching Google and finding partial private keys, e.g. ---- BEGIN PRIVATE KEY ---. Even with text missing, it is trivial to recover the entire key, because of redundancy that Akama…

Great talk, thanks for the link. I've used DJB's software for years, but this was the first talk I've seen.
Post reply on HN