Slashdot Mirror
Private Keys Stolen Within Hours From Heartbleed OpenSSL Site
Billly Gates (198444) writes "It was reported when heartbleed was discovered that only passwords would be at risk and private keys were still safe. Not anymore. Cloudfare launched the heartbleed challenge on a new server with the openSSL vulnerability and offered a prize to whoever could gain the private keys. Within hours several researchers and a hacker got in and got the private signing keys. Expect many forged certificates and other login attempts to banks and other popular websites in the coming weeks unless the browser makers and CA's revoke all the old keys and certificates."
I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge. But, still, this proved it's possible.
So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
#DeleteChrome
What do you mean, punish? Free certificates for all. The other AC is spot on. This is a make or break moment for the CAs. Unless they ensure that all vulnerable keys can no longer be used, the CA model is terminally damaged. The only way to make sure that all clients reject all vulnerable certificates is to change the root certificates and issue new certificates to everybody. If neither the CA nor the browser makers take this admittedly drastic step, I predict extensions soonish which will reject certificates issued before 2014-04-08. Either way, all certificates will have to be replaced soon.
Coverity is a static analysis tool. It was tested on the source code with the Heartbleed vulnerability and did not find it. The developers of Coverity made a proof-of-concept modification to treat variables as tainted if they're subjected to endianess conversion, based on the assumption that such variables contain external and thus potentially hostile data. With this modification, Coverity finds the Heartbleed bug, as described in this blog post. Note the comment below the screenshot: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here." This may just be a consequence of not detecting all ways in which a tainted variable is sanitized, or it may point to more problems.
The problem with replacing HTTPS is that you will need to maintain regular HTTPS for all those clients that cant upgrade to a newer browser. (which exposes web sites to these threats) And you have to convince browser and web server vendors to support the new HTTPS replacement.
Google would probably do it (on desktop, ChromeOS, Android and its custom web/SSL server software) especially if it made it harder for the kind of man-in-the-middle-using-fake-certificates type attacks the NSA have been using (the ones that let the NSA serve up fake copies of popular web sites as a vector to infect other machines). Opera and others that use the Google rendering engine would probably use the Google support.
Mozilla would probably do it if you could convince them that its not just going to be bloat that never gets used.
Apache would probably support it via a mod_blah and if they dont, someone else would probably write one.
Other FOSS browsers and servers (those that do HTTPS) would probably support it if someone wrote good patches.
But good luck convincing commercial vendors like Microsoft and Apple to support a new protocol. And the Certificate Authorities would fight hard against anything that made them obsolete (which any new protocol really needs to do)
OK, then they should invalidate ALL certificates, test customers for the patch, give patched customers new certs, and refuse to give new certs to unpatched customers. It's their business to maintain a 'web of trust'.
There is probably still a great deal of unpatched openSSL deployments out there..
I think you miss the GP point. I believe the GP is saying that the site could have been exploited for a while and the damage has already been done. The check just tell us that the site has been patched but NOT tell us how much the damage is done to users. As a result, some users do not know that their username/password have already been stolen by the exploitation (which is not caused by the user). I doubt that there is a gray area allowed in security. Once the security is breached, there is no guarantee to say that everything is now fine after the fixed/patched.