We have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1620772 with the findings of our current investigation.
We believe all issues raised in this thread are addressed in this update. Our investigation is ongoing and we welcome any positive input by the community as an opportunity to improve our practices and communal PKI operations generally. Our team is evaluating possible improvements for this process, such as acquiring actual public keys created by the weak Debian RNG and using those keys to produce fingerprints compatible with our CA software. We have also contacted our CA software vendor regarding an improved blacklist. csk Chris Kemmerer SSL.com On Monday, March 9, 2020 at 3:41:09 PM UTC-5, Nick Lamb wrote: > 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
