Re: [nznog] [PAG] Message concerning Certs

https://mobile.twitter.com/1njected/status/453797877672706048 Screen dump of private key data in exploit. Also a claim that it's been done on gentoo @thegrugq https://mobile.twitter.com/thegrugq @1njectedhttps://mobile.twitter.com/1njected Cool! I've recovered it from Apache on Gentoo as a bare prime factor in binary, but your demo's a lot clearer. https://mobile.twitter.com/makomk/status/453829416003850240 Seriously guys enough with the equivocation. It's an exploit in the wild that exposes your private key material. Patch, Revoke and Reissue. On Wednesday, April 9, 2014, Dean Pemberton wrote:

And from the same twitter thread saying it was unlikely...

@neelmehta https://mobile.twitter.com/neelmehta @tqbfhttps://mobile.twitter.com/tqbf We can extract the private key successfully on FreeBSD after restarting apache and making the first request with ssltest.py 6:27pm - 9 Apr 14 https://twitter.com/1njected/status/453781230593769472

https://mobile.twitter.com/1njected/status/453781230593769472

On Wednesday, April 9, 2014, Ewen McNeill javascript:_e(%7B%7D,'cvml','nznog(a)ewen.mcneill.gen.nz');> wrote:

...

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 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog