Akamai Reissues All SSL Certificates After Admitting Heartbleed Patch Was Faulty 56
SpacemanukBEJY.53u (3309653) writes "It took security researcher Willem Pinckaers all of 15 minutes to spot a flaw in code created by Akamai that the company thought shielded most of its users from one of the pernicious aspects of the Heartbleed flaw in OpenSSL. More than a decade ago, Akamai modified parts of OpenSSL it felt were weak related to key storage. Akamai CTO Andy Ellis wrote last week that the modification protected most customers from having their private SSL stolen despite the Heartbleed bug. But on Sunday Ellis wrote Akamai was wrong after Pinckaers found several flaws in the code. Akamai is now reissuing all SSL certificates and keys to its customers."
Do I get this right: (Score:3)
Re: (Score:1)
Still doesn't answer the question if the Akamai code was vulnerable to Heartbleed in the first place.
Everything is vulnerable to Heartbleed.
Re:Do I get this right: (Score:4, Funny)
I'm glad to learn that my toaster is vulnerable to Heartbleed.
Re: (Score:1)
Leaking up to 64mg of peanut butter per request!
Re:Do I get this right: (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re:Do I get this right: (Score:4, Informative)
IIS is not. It uses schannel, not OpenSSL.
Re: (Score:3)
Going off on the Windows OS codebase and license in a heartbleed discussion? No personal vendetta detected here, no sir.
Seriously, a discussion on how FOSS dropped the ball so seriously that private keys are being disclosed is not the time to bring up complaints about Windows.
Re: (Score:2)
I was completely unaffected by Heartbleed even though there are dozens of SSL sites on my servers.
It turns out A10 load balancers don't use OpenSSL. :)
Re: (Score:3, Informative)
The fact that they are re-issuing certificates clearly indicates that they were open to Heartbleed. They had tried to add another layer of protections to protect against bugs like this (which is honorable), but found that they were insufficient to protect the certificate. I haven't read up on the details, but it is likely that temporary decryption operations exposed enough information so that the ssl key could be regenerated, even if the ssl key itself was protected. Crypto is difficult, and trying to pr
Re:Do I get this right: (Score:4, Insightful)
The fact that they are re-issuing certificates clearly indicates that they were open to Heartbleed.
That seems to be the US thing, where trying to fix a problem is taken as admission of guilt. (I heard this weird story that US hospitals have a problem if one of their X-ray machines breaks and the replacement is a better model, because anyone examined using the older machines can claim they didn't get the best possible treatment).
They deserve congratulations ... (Score:5, Insightful)
for having the integrity to admit that they screwed up the first time.
Re: (Score:2)
for having the integrity to admit that they screwed up the first time.
Absolutely. So many companies would have tried to say that protection was "good enough" or "unlikely to be exploitable in real situations".
Re:They deserve congratulations ... (Score:4, Interesting)
Here's to hoping they are rewarded for their prompt honesty, rather than persecuted, as we certainly need to set some positive precedents for this exact type of conduct.
Financial Institution Vulnerabilities? (Score:3)
Earlier this morning, I read on another post that someone was saying how Heartbleed compromised many bank's systems. This was contrary to what was posted on sites such as CNET that provided a list of providers and websites that claim they were not vulnerable. It sounded incredulous. Frankly, still does.
I can see financial institutions using an open solution for their public facing websites. But, how many actually "run" an operating system that is based on Open Source for their financial transactions? Exactly. Most, I suspect, are likely running another fully patched, proprietary OS and few, if any, would be permitted to run on public or open software. Still, those customer facing systems could be compromised and there might be a way to capture a customer's banking credentials.
The good news is, if your bank is FDIC insured, your money is safe - up to the limit of the Insurance ($250K???) Still, it's a major inconvenience. And, while there is genuine concern here, there is too much FUD being spread.
What is really needed right now is a secure, public, searchable list of sites that are vulnerable, not vulnerable and unknown. And, institutions what have your contact information or sensitive information (ie. credit card info) should be contacting all customers to inform them if their data or accounts might have been compromised, what actions are being taken, and what actions the customer must take (such as when it's safe to actually change one's password, force a password reset, go to 2 factor authentication, etc).
Lastly, I can understand why a mobile device might not check a certificate revocation list. But, there is no excuse for a desktop server to not check the SSL cert's validity. And, if the user still wants to go to the site, the warning should remain on the screen a highly visible form (like putting a BIG red border about the frame with text reading (THIS SITE MAY HAVE BEEN COMPROMISED) .
Re:Financial Institution Vulnerabilities? (Score:4, Insightful)
What is 'verisign' ... I mean, I know of the company named verisign that functions as a root CA, but they don't have magical certs that are safe, they are just like all other certs.
A quick Google search yields too much about the company, can you point me at what you're referring to so I can clear my ignorance?
Re: (Score:2)
Actually Verisign is a company that runs the root DNS for .com and .net, among some other TLDs. They don't do security or certification.
You're thinking of Symantec.
Re: (Score:1)
... You have not worked directly with banks and their development teams have you?
If you had, you would know you were wrong...
Re: (Score:3)
Indeed. Bank managements are interested in making money, not spending it on IT. A big part of JPMorgan's present problems (and some forthcoming ones that have not hit the fan yet, according to rumor) are due to their CIO's refusal to implement required IT risk management, despite repeated warnings from their auditors. If they fail this aspect of the audit a third time, hundreds of pension funds will be required by law to provide personnel to stand behind the JPM traders and monitor their activities - or
Re: (Score:1)
This was contrary to what was posted on sites such as CNET that provided a list of providers and websites that claim they were not vulnerable. It sounded incredulous. Frankly, still does. I can see financial institutions using an open solution for their public facing websites. But, how many actually "run" an operating system that is based on Open Source for their financial transactions?
What's a financial transaction, per say?
Do you want people logging into your online account overview?
And there's the damning rub - most of the, "LOL LOOK GAIZ NO HEARTBLEED!" lists are testing the main websites of banks. They're not testing online banking portals.
Re: (Score:2, Informative)
I can see financial institutions using an open solution for their public facing websites. But, how many actually "run" an operating system that is based on Open Source for their financial transactions?
Many of them run their online banking websites on java, websphere, IIS and the like.
And the issue isn't with the operating system, the issue is with an application, OpenSSL, which runs on many different operating systems.
The good news is, if your bank is FDIC insured, your money is safe - up to the limit of t
Re: (Score:2)
In fact, the original code (with the bug) is more ordered and clear than the patch. But in general, the issue is that OpenSSL is a very big and complex piece of code maintained by a group of people with a very small quantity of resources, but being used by many important organisations around the world.
The problem is not that the software is open source. The proprietary source also have the same level of p
More than a decade ago... (Score:2)
More than a decade ago, Akamai modified parts of OpenSSL it felt were weak related to key storage
Now that's insight!
Re: (Score:3)
Well, when you're running edge cache servers that service gazillions of SSL sites and need to store a private key for each on each of those distributed servers, you're pretty much going to be modifying quite a lot of stuff.
Re: (Score:2, Insightful)
a) I would not say this is the worst ever - it allows random data to be viewed, which may or may not contain something valuable. There is no evidence (yet) that this was actually exploited prior to its publication. Various other breeches have resulted in proven loss of millions of identities, and near-billions in actual money. If it had been exploited very much, it would probably have been tracked down earlier.
Technically it's not the worst - it's the same as literally thousands of other exploited bugs,
Re: (Score:2)