The flaw can potentially be used to reveal not just the contents of a secured-message, such as a credit-card transaction over HTTPS, but the primary and secondary SSL keys themselves. This data could then, in theory, be used as a skeleton keys to bypass secure servers without leaving a trace that a site had been hacked.
This bug not a problem with OpenSSL's inherent design. It's an implementation problem. That is to say it the result of a programming mistake. There is already a fix available for the problem for the 1.01 program in OpenSSL 1.0.1g. Work is proceeding rapidly for a pair of the 1.02-beta line.
That's bad enough. but what really has some operating system and security companies ticked is that OpenSSL and others were hard at work at delivering the patched versions that would have limited the problem's possible use by blackhat hackers, CloudFlare, a Web security company, revealed in a blog posting details about the security hole and that they've fixed the bug. They appear to have used the methods described by OpenSSL. Unfortunately, for everyone else, these methods were not ready for broad deployment.
According to one senior security developer at a major operating system company, "The main problem with what CloudFlare did was that they jumped the gun before the FIRST AVAILABLE patches were available to users. You don't open the door and wave a red flag before the patches are ready to go."
John Graham-Cumming. a CloudFlare programmer, insisted that this misrepresented CloudFlare's impact on the news of the Heartbleed security hole since the OpenSSL annoucement had been posted to Hacker News earlier.
At this time, I am informed by sources that Red Hat, Debian, SuSE, Canonical, and Oracle, to name a few, are working at a feverish pace to get the patched versions of OpenSSL out to their clients. It's expected that it may take approximately 12-hours to deliver the patches. When do they become available anyone using OpenSSL 1.01 or 1.02 must deploy the patched version as fast as possible.