Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
On Monday, May 27, 2019, Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote: > > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > > > exposes the Subscriber's Private Key to compromise". > > > > > > Several questions arise from this, which I'd like to get the opinion > of the > > > members of this illustrious debating society: > > > > Have you read through the archives? This was already discussed and > decided > > as part of handling Heartbleed. This was debated at length, in particular > > as at least one (but possibly more) CAs charged for revocation, which > > created challenges and potential conflicts with the contemporaneous BRs > and > > Policy. > > Are you referring to the m.d.s.p archives, or somewhere else? (Perhaps > public@cabforum?) I have, in fact, gone through the m.d.s.p archives, and > I > can't see anything that addresses what I'm asking. I can't even find a > "lengthy" thread in > https://groups.google.com/forum/#!searchin/mozilla.dev. > security.policy/heartbleed%7Csort:date > from around the time of Heartbleed that actually discusses revocation > policy > in any detail, just a couple of big ones that mention it in passing (like > "DRAFT: May CA Communication"). > > The thread that seems to come closest to touching on the issues is from > 2017, and doesn't start off discussing Heartbleed, but rather just a mass > of > compromised keys: https://groups.google.com/d/msg/mozilla.dev.security. > policy/71AXGTgcX9c/skHsKFdDBAAJ > I assume that isn't the discussion you were referring to, because it is so > far removed, temporally, from "handling Heartbleed". > > I would appreciate it if you could point me specifically to the relevant > past discussions, so I can inform myself of the past decision. > > - Matt > > The very first result for “revocation Heartbleed” returns https://groups.google.com/d/msg/mozilla.dev.security. policy/ItSu2bebBKk/VrNXwL-MCZgJ , for example, which also links to https://bugzilla.mozilla.org/show_bug.cgi?id=994033 This also came up during the StartCom distrust decision, also linked from that same query: https://groups.google.com/d/msg/mozilla.dev.security.policy/TbDYE69YP8E/ JpdMjH98GQAJ , which included related bugs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote: > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > > exposes the Subscriber's Private Key to compromise". > > > > Several questions arise from this, which I'd like to get the opinion of the > > members of this illustrious debating society: > > Have you read through the archives? This was already discussed and decided > as part of handling Heartbleed. This was debated at length, in particular > as at least one (but possibly more) CAs charged for revocation, which > created challenges and potential conflicts with the contemporaneous BRs and > Policy. Are you referring to the m.d.s.p archives, or somewhere else? (Perhaps public@cabforum?) I have, in fact, gone through the m.d.s.p archives, and I can't see anything that addresses what I'm asking. I can't even find a "lengthy" thread in https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/heartbleed%7Csort:date from around the time of Heartbleed that actually discusses revocation policy in any detail, just a couple of big ones that mention it in passing (like "DRAFT: May CA Communication"). The thread that seems to come closest to touching on the issues is from 2017, and doesn't start off discussing Heartbleed, but rather just a mass of compromised keys: https://groups.google.com/d/msg/mozilla.dev.security.policy/71AXGTgcX9c/skHsKFdDBAAJ I assume that isn't the discussion you were referring to, because it is so far removed, temporally, from "handling Heartbleed". I would appreciate it if you could point me specifically to the relevant past discussions, so I can inform myself of the past decision. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi everyone, > > In pondering ways of getting yet more keys for pwnedkeys.com, my mind > turned > to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable > servers and pulling their keys is eminently possible (see, as just one > example, https://github.com/robertdavidgraham/heartleech), I recalled that > CAs are responsible for revoking certificates within 5 days (with a > "SHOULD" > of 24 hours) when: > > > The CA is made aware of a demonstrated or proven method that exposes the > > Subscriber's Private Key to compromise, methods have been developed that > > can easily calculate it based on the Public Key (such as a Debian weak > > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence > > that the specific method used to generate the Private Key was flawed > > (Taken from BRs v1.6.3, because that's what I happened to have handy) > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > exposes the Subscriber's Private Key to compromise". > > Several questions arise from this, which I'd like to get the opinion of the > members of this illustrious debating society: > > 1. Do others agree that Heartbleed appears to meet the criteria of this >paragraph in the BRs? > > 2. Assuming "yes" to the above question, is it (still) reasonable to > require >CAs to revoke certificates within 5 days if notified that a certificate >they issued is being served from an endpoint vulnerable to Heartbleed? > > 3. Assuming "yes" to the above questions, should I stand up a tool to watch >certificates coming out of CT logs, identify endpoints serving those >certificates, test them for Heartbleed, and report these facts to CAs > for >appropriate handling? > > Of course, if it's deemed that Heartbleed *isn't* "a proven method etc > etc", > the keys could just be pulled directly, which I'm led to believe typically > takes a lot less than four days (and which would trigger the > 24-hour-required revocation), but it seems to me "politer" to everyone to > use the less intrusive option. > > Additional comments surrounding this issue, not pertaining specifically to > the above three questions, would also be gladly received. > > - Matt > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > Have you read through the archives? This was already discussed and decided as part of handling Heartbleed. This was debated at length, in particular as at least one (but possibly more) CAs charged for revocation, which created challenges and potential conflicts with the contemporaneous BRs and Policy. I don’t see anything new being discussed, so I think the past decision remains applicable. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
If malloc() is correctly implemented, private keys are secure from Heartbleed. So I think it doesn't meet the criteria. CAs can't revoke a certificate without noticing subscriber in advance. But if any bugs found in future which can retrieve private keys from TLS endpoints, you can just use automated tools to scan them and get private keys to request a revoke. I thought this is the best practice to this BR. 在 2019年5月27日星期一 UTC+8上午9:34:31，Matt Palmer写道： > Hi everyone, > > In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned > to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable > servers and pulling their keys is eminently possible (see, as just one > example, https://github.com/robertdavidgraham/heartleech), I recalled that > CAs are responsible for revoking certificates within 5 days (with a "SHOULD" > of 24 hours) when: > > > The CA is made aware of a demonstrated or proven method that exposes the > > Subscriber's Private Key to compromise, methods have been developed that > > can easily calculate it based on the Public Key (such as a Debian weak > > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence > > that the specific method used to generate the Private Key was flawed > > (Taken from BRs v1.6.3, because that's what I happened to have handy) > > That sounds an *awful* lot like Heartbleed: "a [...] proven method that > exposes the Subscriber's Private Key to compromise". > > Several questions arise from this, which I'd like to get the opinion of the > members of this illustrious debating society: > > 1. Do others agree that Heartbleed appears to meet the criteria of this >paragraph in the BRs? > > 2. Assuming "yes" to the above question, is it (still) reasonable to require >CAs to revoke certificates within 5 days if notified that a certificate >they issued is being served from an endpoint vulnerable to Heartbleed? > > 3. Assuming "yes" to the above questions, should I stand up a tool to watch >certificates coming out of CT logs, identify endpoints serving those >certificates, test them for Heartbleed, and report these facts to CAs for >appropriate handling? > > Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc", > the keys could just be pulled directly, which I'm led to believe typically > takes a lot less than four days (and which would trigger the > 24-hour-required revocation), but it seems to me "politer" to everyone to > use the less intrusive option. > > Additional comments surrounding this issue, not pertaining specifically to > the above three questions, would also be gladly received. > > - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")
Hi everyone, In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned to everyone's favourite bug, Heartbleed. Whilst hitting all the vulnerable servers and pulling their keys is eminently possible (see, as just one example, https://github.com/robertdavidgraham/heartleech), I recalled that CAs are responsible for revoking certificates within 5 days (with a "SHOULD" of 24 hours) when: > The CA is made aware of a demonstrated or proven method that exposes the > Subscriber's Private Key to compromise, methods have been developed that > can easily calculate it based on the Public Key (such as a Debian weak > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence > that the specific method used to generate the Private Key was flawed (Taken from BRs v1.6.3, because that's what I happened to have handy) That sounds an *awful* lot like Heartbleed: "a [...] proven method that exposes the Subscriber's Private Key to compromise". Several questions arise from this, which I'd like to get the opinion of the members of this illustrious debating society: 1. Do others agree that Heartbleed appears to meet the criteria of this paragraph in the BRs? 2. Assuming "yes" to the above question, is it (still) reasonable to require CAs to revoke certificates within 5 days if notified that a certificate they issued is being served from an endpoint vulnerable to Heartbleed? 3. Assuming "yes" to the above questions, should I stand up a tool to watch certificates coming out of CT logs, identify endpoints serving those certificates, test them for Heartbleed, and report these facts to CAs for appropriate handling? Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc", the keys could just be pulled directly, which I'm led to believe typically takes a lot less than four days (and which would trigger the 24-hour-required revocation), but it seems to me "politer" to everyone to use the less intrusive option. Additional comments surrounding this issue, not pertaining specifically to the above three questions, would also be gladly received. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
