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
Eg, from a couple of years ago:
And apparently, eg, Chrome doesn't check by default:
(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:
which also references:
(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
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.