Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This seems like an AI-generated summary and it leaves some obvious questions unanswered.

    This thread (linked by the page) seems like a better source: https://groups.google.com/a/mozilla.org/g/dev-security-polic...

    Ian Carroll notes:

    > I think it's worth noting that this compromise is much worse than the private keys simply being stolen by a researcher. They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.

    by lukeschlather
  • I set up a server that responds with a certificate to any host you request. You can use it to see if curl accepts the certificate or not.

    curl https://example.org --connect-to example.org::2.29.126.86:

    by lamonade
  • Browsers are typically very good at revocation of certificates, distrusting intermediate CAs and root CAs. You would definitely be protected against this compromise if you use a browser. Command line tools less so. Try this curl one liner

        curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221'
    If curl returns a response, it means it trusted a fake certificate that allowed this random server at 135.181.235.221 to impersonate google.

    Thanks to mastodon user q3k@hackerspace.pl.

    by kccqzy
  • From what the internet is telling me, the keys were allegedly found on https://repository.emsign.com/certs/<redacted>.crt

    Which, if true, is definitely a lot of fun.

    Hope you people are ready for lots and lots of suddenly hackable IoT.

    __

    Edit: I might also be misinterpreting what I am seeing and it's actually weak logic that created the keys, in the sense that one could guess the private key?

    Someone actually qualified please give credible answers. I'm just pretending.

    by hypfer
  • The impact of this incident is very unevenly spread.

    Over 10 years ago, Mozilla shipped OneCRL [1]. We remediated this incident in a couple of hours for Firefox users who were protected automatically without the need for updates. Chrome, Apple and Microsoft have similar tooling. Since then, we've built more advanced tooling to handle revocation at scale for leaf certs (CRLite [2]).

    However, for the rest of the ecosystem, there has been little to no investment in revocation and for those clients, this is a massive problem. Hopefully, we'll see folks invest now. Efforts like upki [3] look promising.

    [1] https://blog.mozilla.org/security/2015/03/03/revoking-interm...

    [2] https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

    [3] https://github.com/rustls/upki

    by galadran
  • Explanation from eMudhra in the Mozilla bug report https://bugzilla.mozilla.org/show_bug.cgi?id=2083449:

    > We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)

    They don't blame the HSM.

    Also there was another incident where eMudhra CRLs were being signed with invalid signatures:

    > The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.

    by tech234a
  • If you can see this, you're affected. Update your system trust store immediately.

    https://dv-g3b-emudhra.we-have-a-problem.com/

    by denysvitali
  • Since I haven't seen this mentioned enough yet:

    The private key for all 8 "compromised" CAs is a single byte: https://mastodon.catgirl.cloud/@49016/117474217042191790

    One of the private keys is literally "4".

    I'm putting "compromised" in quotes here, because I can't call it that without cringing and cursing.

    [cf. also: https://news.ycombinator.com/item?id=50169109]

    by eqvinox

Explore Birbla archives