Hacker News Reader

Comment by jgrahamc | Hacker News Reader

I would be interested to know if this actually protects against heartbleed in the real world. I can see how it would keep the private key protected, but not sure if it protects intermediate values used during calculation.

Given that it's likely that the private key can be derived from those parts, it would be good to know if this custom allocator is 'enough' (i.e. are the intermediate values stored in memory allocated using the same allocator)?

This week has been full of surprises. Has anyone tested this?

View on HN

I didn't but akamai itself did [1]:

    To test this belief, our engineers have rebuilt 
    every Akamai configuration since August 2012, 
    when we upgraded to openssl-1.0.1. This included 
    every kernel, hardware, and edge server software  
    combination; and then a careful inspection of the ways 
    in which memory was allocated, to see if any 
    non-long-term memory allocations might border 
    on our secure heap. Most of the configurations 
    were proven safe; but we found one configuration 
    that was not - there was an available memory block in
    range of the secure key store.

    This less safe configuration was active on our network
    for nine days in March 2013

[1] https://blogs.akamai.com/2014/04/heartbleed-update.html

That is very impressive. I'm amazed they essentially keep a revision history of their system configuration.

Yes, I'm also very impressed by this. It shows that they have their OPs in total control and know what they are doing.

Thanks!

As someone who grew up in the Akamai ops environment... How else could you get anything done? I've taken this tool for granted since it was built in 2000. I expect every planetary scale computing company to do this. Isn't it what Heroku and similar git-push-to-deploy systems are supposed to get you?

It apparently did for Akamai, though it certainly wouldn't be the first time someone's wrongly thought they were protected from Heartbleed key extraction. It doesn't seem to work in general though; I finally got the version without guard pages working on Debian (the version with them is totally broken and crashes during init) and it doesn't seem to make much difference. Also, it doesn't support threaded servers.

As Rich said: a prototype that works in our world, for our use cases. It needs lots of work to generalize. For example, we have about ten thousand SSL private keys per machine. This, without guard pages, protects all but the first few hundred perfectly. Something else protects those first few hundred (and that something else is a lucky freak accident).

If you load 1000 keys, can you extract anything past the 256th?

Did you actually test this? Because apparently someone looked at the code and found your assumptions are wrong and you're not protecting the private keys as well as you thought you were: http://lekkertech.net/akamai.txt (Also, your blog post appears to be based on the same assumptions.)

Reply on news.ycombinator.com