Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")
On 27/05/2019 04:05, Matt Palmer wrote: On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy wrote: If malloc() is correctly implemented, private keys are secure from Heartbleed. So I think it doesn't meet the criteria. Just to make sure I'm understanding you correctly, you're saying that being vulnerable to Heartbleed doesn't *necessarily* expose private keys, it requires an additional criteria (malloc being "incorrectly implemented"), thus it doesn't fit the definition of a "proven method that exposes the Subscriber's Private Key to compromise"? CAs can't revoke a certificate without noticing subscriber in advance. Can you point me to where that requirement comes from? Some CAs don't necessarily have *any* notification method for their subscribers (Let's Encrypt immediately comes to mind); does that mean they're immune from revocation requirements? Is there any requirement around how quickly CAs are required to notify subscribers, and does that time come out of the 24 hour / 5 day budget, or is it some additional time period? 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. OK, so that's one vote for "just scan the Internet and drop private keys on CAs for revocation within 24 hours". Mass attacking vulnerable systems just to prove they are indeed vulnerable, and without separate explicit invitation by the system owners (buried clauses in terms and conditions don't count) is regarded as highly criminal in most jurisdictions. So that isn't really a good tactic. Also, it should be noted that many vulnerability scanners that don't attack (a seemingly obvious solution) tend to report non-vulnerable systems that happen to have some technical similarity (version number, feature set etc.) as vulnerable. For the Heartbleed example, an OpenSSL library patched to safely handle the heartbeat TLS extension would typically be misdetected as vulnerable. Also, use of a HSM to store the private key would make it not compromised even if used with a vulnerable OpenSSL. So identifying affected certificates from the CA community side in such situations is usually not practical. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ 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.1.1 point 11? ("proven or demonstrated method")
在 2019年5月27日星期一 UTC+8上午10:05:25，Matt Palmer写道： > On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy > wrote: > > If malloc() is correctly implemented, private keys are secure from > > Heartbleed. So > > I think it doesn't meet the criteria. > > Just to make sure I'm understanding you correctly, you're saying that being > vulnerable to Heartbleed doesn't *necessarily* expose private keys, it > requires an additional criteria (malloc being "incorrectly implemented"), > thus it doesn't fit the definition of a "proven method that exposes the > Subscriber's Private Key to compromise"? > > > CAs can't revoke a certificate without noticing subscriber in advance. > > Can you point me to where that requirement comes from? Some CAs don't > necessarily have *any* notification method for their subscribers (Let's > Encrypt immediately comes to mind); does that mean they're immune from > revocation requirements? Is there any requirement around how quickly CAs > are required to notify subscribers, and does that time come out of the 24 > hour / 5 day budget, or is it some additional time period? > > > 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. > > OK, so that's one vote for "just scan the Internet and drop private keys on > CAs for revocation within 24 hours". > > - Matt 1. Yes, it doesn't fit ( for what I thought) 2. I missed some words. please add "without proven fact that the certificate is not secure" I thought what Matt says is not about charge, it is about potential policy to further mass private key compromising. I don't think this have anything to do with StartCom. ___ 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 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
