On 2014-04-09 22:31 , Ewen McNeill 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?
From what I've seen of discussion around certification revocation in the last day or so, it's still pretty unevenly implemented/turned on
For those that are interested, here's a recent (yesterday) discussion of SSL revocation checking: https://www.imperialviolet.org/2014/04/19/revchecking.html TL;DR summary seems to be that there are too many other weaknesses in SSL (such as 1000+ CAs, all equally "trusted" and power of MITM in face of "soft fail" revocation checks -- so MITM just blocks check to revocation service too) that there's little to be gained by turning on revocation checking (which is why it's off in Chrome; Chrome uses an embedded "high risk revocations" list pushed by updates instead, but that's only designed to handle a small volume). Shorter-lived signings that are regularly rolled over (eg, as per the DNSSEC security model) seems a much more viable approach. Ewen PS: OTOH, the last couple of weeks of discussion has illustrated that OpenSSL has the most pessimal memory handling possible for a security library: it not only doesn't wipe the memory immediately after use, it also doesn't give it back to the OS to allow that to happen (and/or the memory to be unmapped), and it reuses the -- uncleared -- memory as soon as possible (so reads of recently used memory are likely to have important things in them). Design fail. (See, eg, OpenBSD list discussion. Apparently the OpenSSL team thought "malloc was too slow" so did their best to avoid getting memory from/giving memory back to the OS....)