I think one large and tricky open question here is what the standard for "suspected of compromise" is.
Most of the people who feel strongly about this issue and are posting here are applying what might be termed a precautionary standard: if there was a conceivable way that something might have been compromised, they suspect it of being so. That's the appropriate attitude for highly valuable or sensitive systems. There's a different metric which can be applied, which is what we actually think the probability of a randomly sampled Class 1 CA cert being compromised in the wild is? In order to evaluate that, there are several sub-questions: 0. What is the probability that the cert was on a vulnerable server? As a baseline, 17.5% of HTTPS servers were vulnerable ( http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html), though perhaps for Startcom Class 1 it's a bit higher, and for people who ask StartCom for revocation it's probably in the 60-90% range. 1. What is the probability that key extraction from the vulnerable server was possible? We don't really have a number here yet. At EFF we've been trying to replicate reports of key extractions, setting up FreeBSD systems with matched library versions, and we haven't succeeded in obtaining portions of any private keys yet. I would guess the probability on a random server is somewhere between 0.1% and 10%, but the confidence interval there is still pretty low. 2. How long was the window of likely successful attack? Widespread attacks began after the announcement of the bug at around 17:30 UTC on Monday 2013-04-07. Researchers in Alex Halderman's group at the University of Michigan were watching for IPv4-wide attack scans, and saw the first one at 23:01 GMT on 2013-04-09. Servers that were unpatched at that point were almost certain to be attacked maliciously. Servers that were near the top of the Alexa charts or otherwise interesting to some attacker accumulated a growing risk of malicious attack as elapsed time after 17:30 UTC on Monday grew. At EFF we have been investigating the possibility that there were attacks in the wild, and we currently think that was probably the case ( https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013), although we have yet to receive any reports of replications of Terrence Koeman's observation. Our current most likely belief is that an intelligence agency did use this bug prior to public disclosure, but not on a widespread basis. Servers that are likely to be of interest to these types of APT actors are in a different risk category to other servers. Overall, where does this leave us? I think the situation is genuinely somewhat ambiguous. Given the current evidence, I think that the vast majority of private keys certified by Startcom remain secret, and this may be sufficient for StartCom to argue that the "suspicion of compromise" is not significantly higher than the baseline in a world filled with malware and bugs to begin with. However it's also clear that rekeying is a sound precaution, and that suspicion of compromise is especially rational for cert holders who (a) ran FreeBSD, (b) failed to get a patch deployed quickly, (c) who are plausible targets for APT attackers, or (d) who were likely to receive a lot of malicious attention after the bug was published. I think the *right* thing for Startcom to do here is to revoke and reissue for anyone who cares to ask. Implementing a new tool that lets that happen automatically, using a signature from the previous key, might be the right way to make that scale. However whether a probabilistic suspicion of compromise is objectively rational depends on a lot of variables, and probably only applies if at least one of (a),(b),(c), or (d) is true. Lastly there's a question about whether all old X.509 certs, or all Startcom certs, or any such category, should be distrusted in bulk. I think it would be a disservice of insane proportions to Mozilla's users, since doing so effectively imposes a TLS tax on every poor admin who has to repair a server knocked over by that action, and the vast majority of certs distrusted in such a campaign were in fact still good and serving to make users safer. One last point: please implement Perfect Forward Secrecy if you haven't already everyone! That's the single biggest thing we can do to reduce the risk created by intelligence agencies' key compromise attacks. On 10 April 2014 07:28, Rob Stradling <[email protected]> wrote: > The Mozilla CA Certificate Maintenance Policy (Version 2.2) [1] says > (emphasis mine): > > "CAs _must revoke_ Certificates that they have issued upon the occurrence > of any of the following events: > ... > - the CA obtains _reasonable evidence_ that the subscriber's private key > (corresponding to the public key in the certificate) has been compromised > or is _suspected of compromise_ (e.g. Debian weak keys)" > > I think that's pretty clear! > > The CABForum BRs go one step further, demanding that the CA revoke _within > 24 hours_. > > AFAICT, non-payment by the Subscriber does not release the CA from this > obligation to revoke promptly. > > Anyone disagree with my interpretation? > > > [1] https://www.mozilla.org/en-US/about/governance/policies/ > security-group/certs/policy/maintenance/ > > > On 10/04/14 15:16, [email protected] wrote: > >> This an interesting issue Kaspar and I appreciate you raising it. I also >> personally appreciate you framing it in terms of trust because that's >> really what is at issue here. >> >> The whole idea of revocation is a gaping hole in the PKI landscape. The >> ability to say "don't trust me" is so poorly implemented throughout PKI as >> to be effectively non-existent. If for some reason you need to revoke a >> cert, you should do so because it's the right thing to do, but the best you >> can hope for is that some anti-security person doesn't figure out a way to >> use it anyway. >> >> This means that theft and other compromises of private keys remain viable >> attack vectors for those who wish to do so (government sponsored >> organizations and otherwise). Private keys and the certs that go with them >> could be usable well after when people think they become invalid. >> >> This also means that we should not be surprised to see an underground >> market appear that seeks to sell "revoked" certs. Given that "high value" >> internet destinations might have been impacted by the Heartbleed >> vulnerability this could definitely become a concern. Should such a place >> appear I would think StartCom - issued certs would easily be included for >> sale. >> >> This also means that all "pay to revoke" policies should be viewed as >> anti-security and we need to "strongly encourage" they be discontinued in >> short order. If a CA wishes to continue such policies I would question >> their trustworthiness. >> >> Further I think we are reaching the point where browsers have to refuse >> SSL connections when OCSP validation fails. I think it's getting harder to >> argue otherwise, but I'll let the Mozilla folks speak to that. >> >> >> ----- Original Message ----- >> From: Kaspar Janßen >> Sent: Thursday, April 10, 2014 4:12 AM >> >> On 10/04/14 10:08, Peter Eckersley wrote: >> >>> Kaspar, suppose that Mozilla followed your suggestion and removed >>> StartCom's root certificates from its trust store (or revoked them!). >>> What >>> would the consequences of that decision be, for the large number of >>> domains >>> that rely on StartCom certs? >>> >> I hope that an appropriate policy will force authorities to reconsider >> their revocation principle. I don't want to harm someone nor I want to >> work off in any way. >> >> The key is that anybody should be able to shout out "don't trust me >> anymore!" without a fee. Isn't that part of the trustchain idea? >> >> I read a few times that Chrome doesn't even check if a certificate is >> revoked or not (at least not the default settings). That leads me to the >> question: Is it mandatory for a CA in mozilla's truststore to have to >> ability to revoke a certificate or is is only an optional feature >> provided by some CAs? >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> >> > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
