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."
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?
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.