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."
Be aware that even the root CA certificates can be at risk right now, and that can really cause problems.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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
The bigger issue is that even people who don't trust the (braindead; but too convenient to die) "Hey! Let's just trust about 150 zillion different 'secure' Certificate Authorities and if they signed the cert and it matches the domain everything must be OK!" are still pretty screwed if whatever specific certificate or certificates they are using are now also in the hands of some unknown and probably malicious 3rd party...
There's a pretty big difference between 'because the system is pretty stupid, you can generate a valid certificate for any domain by knocking over any one of an alarming number of shoddy and/or institutionally captured CAs' and 'your private key, yours specifically, can be remotely slurped out of your system and used to impersonate it exactly'.
Chrome turns the "check for revocation" option off by default, it seems.
Yeah, I had a sig once; I got bored of it.
Fuck.
(Except here in the UK, we are more creative with our profanity.)
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.
There are a couple tools available at:
https://github.com/Lekensteyn/...
It's python based so YMMV
They will tell you if you are vulnerable (See the README.md file)
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.
I am not sure it is a bigger issue, since many of these sites will not be publicly reachable. But it definitely is an issue foe example for large corporations that use SSL in their Intranet with self-signed certificates. They now have to wonder whether some of their staff has attacked their servers this way.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Pff now you're telling me the CA has the authority to tell me which certificates are bad??
If that is an issue, there is nothing stopping you, or anyone, from becoming their own Certifcate Authority. I've done this for my own sites, since I am at least 97% sure I am who I claim to be.
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.
IE 11 (at least) works properly, right out of the box:
There is a problem with this website’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.
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
There is probably still a great deal of unpatched openSSL deployments out there.. and it'll probably be a while before they're all patched (if ever)...
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.