Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
1–10 of 79 posts
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#2(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#3(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)
The tone of his post is rather unfortunate. Still, he raises good points, even if they are put in an unnecessarily aggressive manner.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#4OpenSSL has pretty good support for HSMs in the form of their ENGINE API. It seems like it would be possible to use this layer to move all key handling and crypto operations out of the process that was dealing with TLS. Process isolation seems like a much better way of getting this kind of security than weird allocator tricks.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#5I'd like to see Akamai create a CloudFlare style challenge using their patch and a compromised version of OpenSSL and see if anyone can get the private keys from it.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#6(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)
Pls elaborate
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#7The funny thing is the fact that everybody is ignoring that the patch wasn't a patch. It was a POC (read demonstration) with the notes:
'...This patch is a variant of what we've been using to help protect customer keys for a decade.
This should really be considered more of a proof of concept than something that you want to put directly into production. It slides into the ASN1 code rather than adding a new API (OPENSSL_secure_allocate et al), the overall code isn't portable, and so on. If there is community interest, we would be happy to help work on addressing those issues. 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
#8I'm guessing the patch was broken because they didn't have an actual patch laying around, they had to do a diff against the upstream and try to pick out the relevant parts. That doesn't excuse some of the other errors though, like integer overflows and not checking return codes. That also doesn't excuse the fact that they didn't actually try the patch before sending it out.
There could be other pieces that we're missing, and this patch alone doesn't prove that you can obtain private keys from Akamai's servers with the Heartbleed bug. It just proves that there could be key parts outside of their protected storage area and they suck at creating patches of their modifications. That being said, I'd love to see someone apply Akamai's OpenSSL patch and still pull the key with Heartbleed.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#9A 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 providers. Make sure you have an exit strategy from day one; the ability to push a button to roll keys, switch algorithms, switch cert providers, etc.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#10(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)
The tone of his post is rather unfortunate. Still, he raises good points, even if they are put in an unnecessarily aggressive manner.
How would a less-aggressive tone be better at delivering the necessary info to Akamai and its customers?