Slashdot Mirror
Akamai Reissues All SSL Certificates After Admitting Heartbleed Patch Was Faulty
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."
So Akamai claims that they protected certificates in memory. So that would be independent of the heart bleed bug, if we assume that heartbleed only managed to report "unprotected" data. And someone found that the protection isn't as good as they thought it was. Still doesn't answer the question if the Akamai code was vulnerable to Heartbleed in the first place. (So that's similar to the claims that OpenSSL didn't use malloc and therefore data had less protection, which doesn't make the Heartbleed bug less bad, but could have protected some data).
for having the integrity to admit that they screwed up the first time.
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) .
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.