On Sun, 8 Mar 2020 10:57:49 +1100 Matt Palmer via dev-security-policy <[email protected]> wrote:
> > The fingerpint of the claimed Debian weak key was not included in > > our database. > > I think it's worth determining exactly where SSL.com obtained their > fingerprint database of weak keys. The private key in my possession, > which I generated for inclusion in the pwnedkeys.com database, was > obtained by using the script provided in the `openssl-blacklist` > source package, with no special options or modifications. Yes, I would certainly want SSL.com's report to give me confidence that #1 they've identified why they didn't spot this key, were there (many?) other keys which would also have been missed? #2 they now have a complete and accurate list of such keys #3 they went back and did the work to re-check other certificates they've issued for this (these?) extra weak keys and any matches were revoked and the subscriber contacted Depending on the circumstances in #1 there may well be a lesson for other CAs, especially if using a setup which is similar in some way to SSL.com and so this point is very important. There might also be further questions about SSL.com's processes which failed to detect this mistake. This sort of incident is also important because of the impact on the Subscriber. Had this subscriber used a different CA with a complete list they'd have been informed immediately that their chosen key was a problem. Because SSL.com didn't do that in fact this subscriber was potentially vulnerable to active, and in some cases even passive attacks on their TLS services for the period between issuance and discovery. Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
