Forgot your password?
typodupeerror
Security Programming

Akamai Reissues All SSL Certificates After Admitting Heartbleed Patch Was Faulty 56

Posted by samzenpus
from the try-it-again dept.
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."
This discussion has been archived. No new comments can be posted.

Akamai Reissues All SSL Certificates After Admitting Heartbleed Patch Was Faulty

Comments Filter:
  • by gnasher719 (869701) on Monday April 14, 2014 @09:01AM (#46746213)
    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).
    • Still doesn't answer the question if the Akamai code was vulnerable to Heartbleed in the first place.

      Everything is vulnerable to Heartbleed.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      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

      • by gnasher719 (869701) on Monday April 14, 2014 @09:44AM (#46746643)

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

  • by Alain Williams (2972) <addw@phcomp.co.uk> on Monday April 14, 2014 @09:05AM (#46746239) Homepage

    for having the integrity to admit that they screwed up the first time.

    • by Chrisq (894406)

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

    • by rmdingler (1955220) on Monday April 14, 2014 @09:20AM (#46746381)
      Yes. The corporate opposite of General Motors trying to explain to Congress the years-long lapse in reporting and repairing the ignition problems of millions of vehicles.

      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.

  • by Ronin Developer (67677) on Monday April 14, 2014 @09:24AM (#46746431)

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

    • by Anonymous Coward

      ... You have not worked directly with banks and their development teams have you?

      If you had, you would know you were wrong...

      • 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

    • by Anonymous Coward

      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)

      by Anonymous Coward

      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

    • by malvcr (2932649)
      I was checking the source code of the original and the "official" (not the Akamai) patch itself.

      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, Akamai modified parts of OpenSSL it felt were weak related to key storage

    Now that's insight!

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

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982

Working...