Akamai Admits Its Heartbleed Patch Was Faulty, Has To Reissue All SSL Certs And Keys
from the ouch dept
The web is a dangerous place these days. Akamai, which many large companies rely on for hosting as a CDN, has admitted that its Heartbleed patch was faulty, meaning that it was possible that the SSL keys “could have been exposed to an adversary exploiting the Heartbleed vulnerability.” Akamai had already noted that it was more protected against Heartbleed than others, because of custom code it had used for its own OpenSSL deployment. However, as researchers looked through that custom code, they found some significant defects in it. Some people have been arguing that the Heartbleed bug highlights a weakness in open source software — but that’s not necessarily true. Pretty much all software has vulnerabilities. And, sometimes, by open sourcing stuff you can find those vulnerabilities faster.
Filed Under: encryption, heartbleed, openssl, patch
Companies: akamai
Comments on “Akamai Admits Its Heartbleed Patch Was Faulty, Has To Reissue All SSL Certs And Keys”
And sometimes the people who need to know about the vulnerability will actually hear about it because it is open source and you can see the code that you’re placing your trust in.
They're trying
Akamai submitted it’s first suggestion to improve upon OpenSSL’s code this week. They are opening discussion with the small team of OpenSSL with their experience in security programming. From what I hear, OpenSSL is nearly all shitty code. Rome wasn’t built in a day, so give the Akamai programmers a chance to sort through the major bugs before posting. They’re trying to help.
“Some people have been arguing that the Heartbleed bug highlights a weakness in open source software …”
Those people have nothing on which to base this.
Re: Re:
Hey they are all “Microsoft Certified Professionals”, more than qualified IMO!
If Akamai hadn’t open sourced their patch code, they probably would have never known about the flaws in their secure memory allocation technique, for encryption keys. Their customers still would have had a false sense of security and might have chosen to not revoked their website’s certificates.
That’s what free and open source software is all about. FOSS is about allowing people the freedom to run, study, copy, and redistribute changes they’ve made to source code.
Heartbleed was discovered using fuzz testing. Fuzzing also works on closed source software.
OpenSSL.org, Codenomicon, Google, Cloudflare, Fedor Indutny, Akamai, and Willem Pinckaers of Lekkertech all collaborated to understand and fix Heartbleed. That’s only listing a few of the parties involved.
That’s a lot of collaborating, and things are getting fixed the right way because of it. It’s hard to tell if something is getting fixed the right way if it’s closed source. We just have to take someone’s word that it is, seeing as there’s no way to verify the fix.
So hats off to Akamai for going the open source route. Their company and customers, are now wiser and more secure because of it.
Re: Re:
A million times that. And we know there’s money to be made even if your code is open and freely available.
As Theo put it: OpenSSL is not developed by a responsible team. OpenSSL has exploit mitigation countermeasures to make sure it’s exploitable.
It has been strongly suggested you move to GnuTLS or even PolarSSL.
Also, what’s been going rather under the radar lately is the fact that every other service that was compiled using the bad OpenSSL versions could also be vulnerable. People have been blindly re-issuing https certificates while leaving the same old vulnerable imap cert online. Media reporting at its finest.
“Some people have been arguing that the Heartbleed bug highlights a weakness in open source software — but that’s not necessarily true.”
Actually, it highlights one of the great strengths of open source software: collaboration. Look at the speed with which this problem was addressed: the timeline is measured in HOURS, not days or weeks or months — which is quite common for closed-source software. Look at the number of independent clueful eyeballs that were brought to bear. Look at the aggregate reaction, which more-or-less boils down to “Hey, we really ought to put some money and time into OpenSSL so that we reduce the probability that this will happen again”.
No closed-source software project has ever come remotely close to this. None ever will: its very nature prevents it.
Open source programming has it clear benefits…but its limitations are in part exposed by this “bug”.
Closed source (propriety) programming has its limitations as well, and even with a large team “bugs” are inevitable.
Still, is does make me wonder which of the two systems is more likely discover such “bugs” and implement a fix in a more timely manner to mitigate future damage.
For all the praise open source receives here and closed course does not, it seems to me that pros and cons are oftentimes not fairly allocated to each.
Re: Re:
Assuming programmers of equal ability, the bug rates should be about the same. With open source software there is definitely more reviewing of the software, often nonofficial, and unrecorded, which should bugs being found more quickly. Also patches for open source software are produces and circulated much more quickly than with closed source software. Also, in open source, bug patches can be, and often are, submitted by someone who stumbles on a bug, while in proprietary software often requires management approval for someone to work on a bug, and they can left in code until customers complain, or an exploit is in use.
On potential big difference between the two is deliberate attacks on security, with open source software these are effectively limited to introducing a subtle bug that can be exploited. With closed source software, it would be possible to introduce a deliberate backdoor, dependent on some magic value being passed to the software. Such a backdoor, unlike a subtle bug, is almost immune to detection by fuzzing, as it requires one or more magic values to activate, and these are unlikely to be found by random chance.
Re: Re:
Why do you keep putting “bug” in quotes? Are you suggesting it’s not really a bug?
Re: Re:
“even with a large team “bugs” are inevitable.”
I would say especially with large teams.
“Still, is does make me wonder which of the two systems is more likely discover such “bugs” and implement a fix in a more timely manner to mitigate future damage.”
No need to wonder. There’s a track record for both open and closed source, and open source software wins on all three of those issues.