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: , , ,
Companies: akamai

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Akamai Admits Its Heartbleed Patch Was Faulty, Has To Reissue All SSL Certs And Keys”

Subscribe: RSS Leave a comment
Nathan Blazek (user link) says:

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.

Anonymous Coward says:

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.

Anonymous Coward says:

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.

Rich Kulawiec (profile) says:

“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.

Anonymous Coward says:

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.

Anonymous Coward says:

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.

John Fenderson (profile) says:

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.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...