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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: encryption, heartbleed, openssl, patch
Companies: akamai
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
They're trying
[ link to this | view in chronology ]
Those people have nothing on which to base this.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]