5 ms·

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

by cscott 12y ago

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 they are supplying this code as assurance that customer keys were properly protected against exposure by the Heartbleed bug and that certificate replacement is not needed, the patch and the subsequent criticism should give Akamai customers pause. edit: Akamai acknowledges the bug, and has started rotating all customer SSL keys/certificates, per https://blogs.akamai.com/2014/04/heartbleed-update-v3.html https://blogs.akamai.com/2014/04/heartbleed-update-v3.html

jackalope 12y ago
It's a smokescreen. If you were running a version of OpenSSL that supported the HEARTBEAT extension (patched or not) it's easy enough to determine whether or not it was vulnerable, simply by running the exploit code. Any theoretical discussion of how your patch made it invulnerable is pure speculation. They can release packet captures that prove they were invulnerable without releasing any code at all. At this stage, it's all PR.
paulhodge 12y ago
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/51246 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.
- awalton 12y ago
  > Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code. All code is bogus code until reviewed. That is absolutely central to understand. Linus's Law only works _if_ people are looking at the code. Implicitly thumbs-upping it doesn't solve problems. Akamai submitted the code, people reviewed it and found flaws. They're taking action to fix their own code, and the community is coming up with various fixes of their own. That's how Open Source Software Development should work. While I agree with you that it'd probably be better to rewrite the code with a similar approach, it's also important to note that nobody in the OpenSSL community even considered this approach publicly until Akamai published their code. Any claims they're being disrespectful of people's time is specious - they said from the beginning that this code needed review and shouldn't be merged. This is just one of those issues that comes out in the wash of code review. TL;DR: Akamai should be lauded on their intentions but like noted by everyone, the code wasn't good enough. Now, with proper review and rewrites, they will be able to protect their customers into the future, and maybe OpenSSL will become a slightly better product for it too.
brians 12y ago
It was released as both: we thought that our old protection against swap protected us against Heartbleed. What a stroke of luck. We did check for key values visible in the heap, and on our implementation, in our lab, didn't find them on any version of our software used since we took OpenSSL 1.0.1. We weren't looking for the CRT values. As one part of our response, we decided to publish the code we thought was keeping us safe. If we were right, sure, there's good PR from that. If we were wrong, it's a chance to find out and get right. Less wrong, anyway.
- cscott 12y ago
  Decisions were made about certificate revocation based on assumptions about this code and Akamai customers ended up being exposed. Perhaps third-party security validation of such a critical piece of code should be a prerequisite before asserting that no further countermeasures such as key rotation were necessary. Such an action would demonstrate significant diligence as compared to a public release days after you've told customers there was nothing to worry about. Additionally, that public release didn't directly encourage security review, the deprecating comments on the post were primarily around portability and design.

by cscott 12y ago

jackalope 12y ago

It's a smokescreen. If you were running a version of OpenSSL that supported the HEARTBEAT extension (patched or not) it's easy enough to determine whether or not it was vulnerable, simply by running the exploit code. Any theoretical discussion of how your patch made it invulnerable is pure speculation. They can release packet captures that prove they were invulnerable without releasing any code at all. At this stage, it's all PR.

paulhodge 12y ago

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

awalton 12y ago
> Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code. All code is bogus code until reviewed. That is absolutely central to understand. Linus's Law only works _if_ people are looking at the code. Implicitly thumbs-upping it doesn't solve problems. Akamai submitted the code, people reviewed it and found flaws. They're taking action to fix their own code, and the community is coming up with various fixes of their own. That's how Open Source Software Development should work. While I agree with you that it'd probably be better to rewrite the code with a similar approach, it's also important to note that nobody in the OpenSSL community even considered this approach publicly until Akamai published their code. Any claims they're being disrespectful of people's time is specious - they said from the beginning that this code needed review and shouldn't be merged. This is just one of those issues that comes out in the wash of code review. TL;DR: Akamai should be lauded on their intentions but like noted by everyone, the code wasn't good enough. Now, with proper review and rewrites, they will be able to protect their customers into the future, and maybe OpenSSL will become a slightly better product for it too.

brians 12y ago

It was released as both: we thought that our old protection against swap protected us against Heartbleed. What a stroke of luck. We did check for key values visible in the heap, and on our implementation, in our lab, didn't find them on any version of our software used since we took OpenSSL 1.0.1. We weren't looking for the CRT values. As one part of our response, we decided to publish the code we thought was keeping us safe. If we were right, sure, there's good PR from that. If we were wrong, it's a chance to find out and get right. Less wrong, anyway.

cscott 12y ago
Decisions were made about certificate revocation based on assumptions about this code and Akamai customers ended up being exposed. Perhaps third-party security validation of such a critical piece of code should be a prerequisite before asserting that no further countermeasures such as key rotation were necessary. Such an action would demonstrate significant diligence as compared to a public release days after you've told customers there was nothing to worry about. Additionally, that public release didn't directly encourage security review, the deprecating comments on the post were primarily around portability and design.