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.
Most sites don't have PFS enabled, and that means anyone who has recorded a site's traffic prior to the publication of the bug only needs a short time to get the key and can then decrypt all recorded sessions. The Heartbleed exploit doesn't just jeopardize the data that is currently flowing through OpenSSL while the attacker is reading server memory through malicious heartbeat requests. If you used a vulnerable server via a public Wifi hotspot in the past two years and someone else recorded your session, then your data is potentially readable. No certificate revocation can fix that. The longer vulnerable servers have been kept online after the disclosure, the more attackers had a chance to get private server keys. These private keys compromise recorded traffic and they enable attackers to pose as the server in the future, because certificate revocation is utterly broken. Keeping vulnerable servers running for any amount of time was reckless.
IMHO browsers should treat all existing certificates as untrusted. All certificate authorities should renew their root CA certificates and have old certificates removed from client software. The system is broken, but without making sure that all potentially compromised certificates are made unusable, many server admins will just keep using old certificates, and then there's no reason to trust SSL at all.
And enable PFS, FFS!
Nah, the browsers will just reset 'zero epoch' for SSL certificates they'll accept to ONLY accept certificates issued after some date post-exploit, and all major SSL vendors will likely reboot their intermediate keychains so there's only a handful of 'revocation' certificates that will actually be needed due to the tree-of-trust model: Anything in the chain gets revoked everything below it goes away.
And yes, this means the folks that were Johnny on the Spot about reissuing their certs might have to re-issue them AGAIN due to fixing their issue so quickly, but that's honestly pretty minor compared to the huge swaths of forever-vulnerable sites that need to effectively have their SSL status revoked regardless of what they do or don't do.
WolfWings, who hasn't logged into SlashDot in YEARS.
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.
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.
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?
I'd guess "because online checking can be slow - as in literally _seconds_ before site starts loading!!11!" and "there's offline revocation list and Chrome updates often enough".
Or may be "because NSAMI6KGB paid us to weaken the security".
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's only free if admin's time is free and CA's time is free. Issuing certificates is not something all CAs can simply do one-sidedly and automatically. I take it you never had to manage certificates, did you?
Only a week passed and already most Internet users won't see a site that didn't take care of that. The wave of reissuing and revoking is still growing, so most of vulnerable certificates will disappear pretty soon.
Meanwhile, you're talking about wasting billions on the off chance a site with a hundred users was interesting enough for someone who could and would effectively MITM it - note that while grabbing the key only takes luck and time, actually using it requires much more.
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.
Time for SHTTP. The useless certificate authorities can go and die in a dark hole. Your bank can send you their public key. For most places you wouldn't even need a password.
OpenSSH is developed by competent people and it has virtually no preauthentication attack surface.