Heartbleed certificate revocation tsunami yet to arrive(news.netcraft.com)
news.netcraft.com
Heartbleed certificate revocation tsunami yet to arrive
http://news.netcraft.com/archives/2014/04/11/heartbleed-certificate-revocation-tsunami-yet-to-arrive.html
3 comments
"We fixed the flaw on Monday March 31, 2014 for all CloudFlare customers, with public notification on Monday April 7, 2014, after the researchers' public announcement." https://support.cloudflare.com/hc/en-us/articles/201660084-U...
Out of curiousity, it there really any benefit to revoking a certifcate? Most (all?) of the leading browsers do not check the revocation list, so this move seems like an empty gesture. Is the Internet vulnerable to MITM attacks until this generation of certificates expire?
Do you think Firefox, Chrome will release an update in the next few weeks with revoked certificate checks enabled?
Do you think Firefox, Chrome will release an update in the next few weeks with revoked certificate checks enabled?
To really protect against active attacks, browsers can't just re-enable OCSP checking (i.e. return to the status quo as of a few years ago). They would also need to make failure to contact the OCSP server a fatal error (something which I don't think has ever been done by default before), and that would probably cause so many problems I can't imagine the browsers doing that.
Personally, I'm never again going to buy a cert that's valid for more than 1 year, and even that's too long. Google uses certs that are valid for only a few months, but they're only able to do that because they are their own certificate authority.
Personally, I'm never again going to buy a cert that's valid for more than 1 year, and even that's too long. Google uses certs that are valid for only a few months, but they're only able to do that because they are their own certificate authority.
AFAICT, here isn't really any benefit for most people. If you're using an Extended Validation certificate the revocation would remove the EV presentation in most browsers.
The only way you'd get a browser to totally fail to load the page in the case of a MITM that can block the OCSP servers is Chrome's CRLSets. Only a limited set of revocations are included due to space constraints though; mostly EV certs from select CAs and Intermediate CA certs.
A good solution to this problem would be short lived certificates, but that idea has yet to find much traction.
http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-shortliv... http://dev.chromium.org/Home/chromium-security/crlsets http://blog.spiderlabs.com/2011/04/certificate-revocation-be...
The only way you'd get a browser to totally fail to load the page in the case of a MITM that can block the OCSP servers is Chrome's CRLSets. Only a limited set of revocations are included due to space constraints though; mostly EV certs from select CAs and Intermediate CA certs.
A good solution to this problem would be short lived certificates, but that idea has yet to find much traction.
http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-shortliv... http://dev.chromium.org/Home/chromium-security/crlsets http://blog.spiderlabs.com/2011/04/certificate-revocation-be...
At godaddy, seems the flare has been lit:
http://support.godaddy.com/godaddy/openssl-and-heartbleed-vu...
http://support.godaddy.com/godaddy/openssl-and-heartbleed-vu...
Could this be the day Google, CloudFlare, and other major internet companies in-the-know before the public disclosure, patched their servers?
Is this graph generally available, for any time range, from NetCraft or another monitoring service?
I'm aware the graph shown has a time range too narrow to conclude anything but this made me think that monitoring this graph or noticing unusual reissues from major internet services (Google/CloudFlare/AWS/Facebook) could be used as an advance warning mechanism that a significant SSL flaw is about to be publicly disclosed.