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

Reply via email to