On 2014-04-09 20:36 , Don Stokes wrote:
Also, last time I worried about this, certificate revocation was, uh, largely unimplemented. That was a while ago. How well does it work now? And with potentially large numbers of revoked certs?
From what I've seen of discussion around certification revocation in the last day or so, it's still pretty unevenly implemented/turned on -- CRL lists aren't updated/checked promptly, and the latency, etc, on the online checks is generally high enough that waiting on results tends not to be done. I'd imagine this can only get worse with a batch of brand new certificates (ie, no cached data on them), and high volume of revoked certificates. Eg, from a couple of years ago: https://www.imperialviolet.org/2012/02/05/crlsets.html And apparently, eg, Chrome doesn't check by default: https://twitter.com/jm/status/453594955538501633 (you can turn it on, but the chances of every visitor to every website turning on that obscure feature are... low) Both via a well written blog post today: http://utcc.utoronto.ca/~cks/space/blog/web/SSLPragmaticKeyCompReactions which also references: https://twitter.com/neelmehta/status/453625474879471616 https://twitter.com/tqbf/status/453680389471879168 (the first from one of the finders of the bug), that indicates memory allocation patterns make private key exposure "unlikely". Obviously "unlikely" is not "impossible". So the paranoid/high risk make wish to treat this like a full fire drill. But from a "well SSL is pretty trivial to MITM if you're well connected" point of view (eg, tame CA on speed dial, or own a sign-everything intermediate, or ...), if you were just using SSL to "raise the bar slightly" on being snooped on, for something low value, patching ASAP and carrying on with life may be a risk/benefit trade off you're willing to accept. I'd caution that it should be a deliberately made choice to do that though. Ewen