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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
