On Tue, Nov 10, 2026 at 2:34 AM Jeffrey Walton <[email protected]> wrote: > > On Sat, Nov 7, 2026 at 9:11 AM Elven Inquisition > <[email protected]> wrote: > > > > Given how trivial it is to crack eMudhra's certs[1], isn't HTTPS useless as > > a > > mitigation[2] for CVE-2026-109518[3] wrt new installations? > > [...] > > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c5 > > [2]: https://ubuntu.com/blog/apt-vulnerability-fixes-available > > [3]: https://security-tracker.debian.org/tracker/CVE-2026-109518 > > [4]: https://cloud.debian.org/images/cloud/trixie/ > > While not obvious, the problem is in the signing process and > signatures of the CRLs. The single byte private exponents are > actually indexes into a HSM slot, and the "keys" used to sign CRLs. > The CRL signing process broke, and the CRLs validation subsequently > failed. That's why the discussion turned to CRLs in Comment 5, > <https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c5>. > > The discussion of HSM slots and the CRL failures happened on the > Mozilla dev mailing list at "Compromised eMudhra Intermediate > Certificates", > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/JESKy8XoAgAJ>. > The discussion of the HSM slots and CRLs starts to happen around 15 > posts in. Start reading on leeyc0's post on Oct 21, 2026, > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/XhSrOzHyAgAJ>. > > Also see Corey Bonnell's post on Oct 21, 2026, > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/QyuemwX9AgAJ>: > > The incident report highlights that no end-entity certificates (and > therefore no OCSP responses) were signed using these CAs. The only > artifacts signed were CRLs, and those failed signature validation using > the CA certificates. That suggests the signing flow used the real HSM > key correctly, and the mistake was limited to CSR generation. > > So the keys that could be used to MitM traffic were still protected in > the HSM and working properly. It was the CRL signing process that > broke and resulted in weak keys. It is not clear (to me) how much > damage an attacker could do since the CRL signatures do not verify. I > do not think an attacker can forge a CRL. If a relying party does not > perform signature checks, then it does not matter whether a strong key > or weak key was used in the process.
My bad, this was only partially correct. Those certs were bad, too. The bad signatures on the CRLs were just a symptom. Jeff
