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."
For all practical purposes, https is dead. There is no way browsers will carry around the hundreds of thousands of possibly-stolen-so-unsafe certificates fingerprints (to consider these tainted/revoked). The only way forward is probably to move away to an incompatible protocol. And if possible, cure some of the X509 wrong ways.
the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?
It's within the CA's right, however, to scan the URLS certified by each certificate, test for Heartbleed vulnerability --- and automatically revoke, if they determine that the site is vulnerable.
Internet Explorer for the win (my head asploded):
There is a problem with this websiteâ(TM)s security certificate.
This organization's certificate has been revoked.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
I feel like I've fallen into Bizarro world, where IE is the safe browser and IIS the safe server. Maybe I should grow a goatee?
Socialism: a lie told by totalitarians and believed by fools.
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?
Netcraft actually has an interesting article about that very situation.
Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.
Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.
Of course, revocation checking for browsers is really bad. Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).
Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).
Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.
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?
Calm down. A majority of web servers are not vulnerable and never were. All in all... less than 30% of SSL sites need to revoke any keys.
Some websites are running with SSL crypto operations performed by a FIPS140-2 hardware security module; these are not vulnerable, since OpenSSL doesn't have access to the private key stored in the server's hardware crypto token.
Many web sites are running on Windows IIS. None of these servers are vulnerable.
Plenty of web sites are running under Apache with mod_nss, instead of mod_ssl. None of the websites using the LibNSS implementation of SSL are vulnerable.
Many web sites are running on CentOS5 servers with Redhat's openssl 0.9.x packages. None of these servers were ever vulnerable.
Many web sites are running on CentOS6 servers, that had not updated OpenSSL above 1.0.0. These websites weren't vulnerable.
Many websites are running behind a SSL offload load-balancer; instead of using OpenSSL. Many of these sites were not vulnerable.
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
Pff now you're telling me the CA has the authority to tell me which certificates are bad??
Oh piss on that!
Yes... That's the entire point of a CA, to certify that a person really is that person. If the certificate is bad, they can no longer make that certification, so it really really really is their job to do that. It is in fact their only job.
It doesn't matter who revokes the keys. Right now only Firefox and Chrome ever check for revoked certs, and Chrome at least has this disabled by default. If you are running iOS or Android, your browser doesn't check the CRL before trusting the cert. So it's great if web sites revoke certs, but it doesn't actually change anything on the end user side, for the most part. I'm not saying anything about Windows platforms because I don't have access to any; it's possible that they do support CRLs. You can check whether your browser supports CRLs by going to this test URL. If you don't get a warning from your browser, your browser isn't checking CRLs.