Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.

exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.

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

Xkcd 221: int getRandomNumber() { return 4; // chosen by fair dice roll. guaranteed to be random. }

top 94 comments

sorted by: hot top controversial new old
[–] 261 points 2 weeks ago* (last edited 2 weeks ago) (17 children)

I think that this isn't really getting the right attention, about what a massive WTF situation this is...

its a 384 bit certificate and this is the private key

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:04

that is just fucking NUTS

  • source
  • hideshow 17 child comments
  • [–] 22 points 2 weeks ago (1 child)

    It's like winning the lottery

  • source
  • parent
  • hideshow 1 child comment
  • [–] 11 points 2 weeks ago

    Winning the lottery is (ballpark) 1 in 10^9, so generating a key below a million is like winning 11 lotteries in a row, while buying 1 ticket in each.

    They wouldn't know how you'd done it, but I think you'd be arrested, with valid probable cause.

  • source
  • parent
  • [–] 10 points 2 weeks ago* (3 children)
    4E:65:76:65:72:20:67:6F:6E:6E:61:20:67:69:76:
    65:20:79:6F:75:20:75:70:20:4E:65:76:65:72:20:
    67:6F:6E:6E:61:20:6C:65:74:20:79:6F:75:20:64:
    6F:77:6E
    

    is much more secure.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 10 points 2 weeks ago (2 children)

    LOL, People are never gonna give this up.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 2 weeks ago (3 children)

    I mean, yes, it’s entirely possible and within the realm of probability of getting that as a key. But realistically it’s very, very, fucking unlikely.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 170 points 2 weeks ago (35 children)

    Okay, that's fun and scary at the same time.

    The article links to a webpage,

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

    That shows if your browser is still using those certs, and though it says Firefox has already updated, maybe it hasn't reached mobile yet as it shows I'm using them all still.

    I guess I won't connect to anything important for a few days.

  • source
  • hideshow 35 child comments
  • [–] 72 points 2 weeks ago (8 children)

    My Firefox mobile got green ✅

    Maybe try manually updating through the app store

  • source
  • parent
  • hideshow 8 child comments
  • [–] 6 points 2 weeks ago* (5 children)

    What's odd is that I have auto updates disabled for Firefox on my spare phone, and I still show green on everything. I don't think it's updated in a couple months now.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 2 weeks ago

    There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.

  • source
  • parent
  • [–] 14 points 2 weeks ago (5 children)

    Useful link, thanks.

    Mobile Waterfox passes.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 2 weeks ago (2 children)

    Interesting. I'm also using Waterfox and getting all red on my end.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 1 point 2 weeks ago* (1 child)

    is the post body having issues displaying? asking because this is way past the first time this season i've seen people not see it

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

    For mobile

    • Vanadium 155.0.8059.84 (config 217) on GrapheneOS connects to 6/12 0/12. Last updated 2026-10-17
    • Fennec 158.0.0 (build #1580020) connects to 12/12. Last updated 2026-10-14
    • edited: after I hit 'run again' a couple times Vanadium went 0/12, so hurray. Didn't make a difference to my dear Fennec though.
  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 2 weeks ago (1 child)

    Uhh... Weird. In my phone (Android 15) both Firefox 158.0.1 and Brave 1.97.59 (Chromium 155.0.8059.85) connect to 6 of the 12 hosts.

    But on my tablet (Android 10) I have the same versions of Firefox and Brave, and there they don't connect to any of the hosts.

    What can I do?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 2 weeks ago (3 children)

    Do you mean not connecting to anything? Because that would be the action if you considered this a threat

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 2 weeks ago (2 children)

    That's... what I said?

    I do consider this a threat. A root certificate being compromised is a big deal. Your web traffic goes across multiple devices before reaching its intended destination, and if any one of them are compromised they could successfully perform an invisible man in the middle attack of your browser/app keeps trusting those certificates.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 weeks ago (1 child)

    Ssl is pretty useful, yeah, but those that were mass unlocked with a gimmick key were already very insecure and at this moment they are revoked. Either way, aren't you supposed to be locked in now?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 weeks ago*

    That only applies to applications and services that support remote certificate revocation.

    Those certificates were still in use until Firefox offered another update this morning, but that's just the browser. Every company and their little bastard love child wants you to use an app to connect to their services, how many of those apps support automatic certificate revocation?

    Any app on your phone that doesn't is now vulnerable to being compromised invisibly. A successful MITM attack looks like nothing at all. The attacker decrypts the traffic with the compromised certificate's secret to snoop in on the secrets (like username and password) and re-encrypts it to send it forward so the destination server doesn't know any different either.

    Now that it's public knowledge, I guarantee someone is trying to capitalize on it right now.

    How certain are you that not a single switch between you and your bank's website is fully secured?

  • source
  • parent
  • [–] 105 points 2 weeks ago* (last edited 2 weeks ago)

    private keys were ... 56

  • source
  • [–] 94 points 2 weeks ago (7 children)

    4, 56, 66, 115, 155, 156, 230, 237.

    That's amazing! I have the same combination on my luggage.

  • source
  • hideshow 7 child comments
  • [+] 60 points 2 weeks ago (4 children)
  • [–] 3 points 2 weeks ago (3 children)

    I hear crypto bros swear by birdbaths xd

    (I read this post 2 years ago and the "Repeat this process six more times with my six other bird baths" stuck with me xD)

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 2 weeks ago (2 children)
  • [–] 114 points 2 weeks ago (7 children)

    As noted, most browsers have already blocked the intermediate certificates. The exception appears to be Edge running on Windows 10, which at the time this article went live was still connecting to 12 vulnerable hosts.

    LOL

  • source
  • hideshow 7 child comments
  • [–] 4 points 2 weeks ago* (4 children)

    Thankfully someone did pull their finger out and get it done an hour later, thankfully Windows also moved to a live CRL requiring no reboots and it's only hundreds of thousand of unpatched Linux boxes that remain affected 😓

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 2 weeks ago* (last edited 2 weeks ago)

    my Ubuntu 24.04 server is secured despite not updating anything or rebooting (I have now, but curl was already declining it before)

    $ curl https://ov-g3c-aaa-emudhra.we-have-a-problem.com/
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: https://curl.se/docs/sslcerts.html
    
    curl failed to verify the legitimacy of the server and therefore could not
    establish a secure connection to it. To learn more about this situation and
    how to fix it, please visit the web page mentioned above.
    

    other issues would be software not respecting the system level certs, but that can happen on any OS, it just depends on the program

  • source
  • parent
  • [–] 1 point 2 weeks ago (2 children)

    Uhhhh as a dumb dumb Ubuntu user, do I need to do anything other than update?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 47 points 2 weeks ago (10 children)

    So if my understanding is correct, to be exploited the attacker would already need to be in a position to intercept your traffic, but this means when they do they can effectively impersonate anyone.

    This could actually be an interesting attack vector for hacking IOT devices. If you control the DNS server the device connects to you can get it to trust literally anything.

  • source
  • hideshow 10 child comments
  • [–] 17 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

    MITM HTTPS traffic without a key doesn't really let you do much of anything, especially with stuff like HSTS. You can mess with DNS, but the whole certificate authority thing is meant to make it so you can't redirect someone's traffic to a malicious server.

    This leaked private key completely destroys that guarantee, making it extremely scary. Plus, saved traffic for any site signed by this key which didn't use PFS will be subject to post-facto decryption.

    edit: I don't know wtf I was thinking, the decryption thing is nonsense.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 9 points 2 weeks ago (1 child)

    I don't think so about the post-facto decrypt. Keyexchange runs with the certs of the destination server. The cerst affected by the leak are intermediate certs which give trust to a cert chain AFAIK.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 weeks ago* (5 children)

    Wasn't the Gamer's Nexus video on LG spy TVs, saying that the telemetry traffic is protected by SSL and thus they couldn't figure out exactly what was sent? Would they be able to use the leaked keys to decrypt the traffic?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 2 weeks ago* (4 children)

    That should be possible yes, depending on how those TVs handle their cert stores.

  • source
  • parent
  • hideshow 4 child comments
  • [–] [S] 2 points 2 weeks ago (1 child)

    wait how would that work? don't LG TVs use a random CA that likely isn't eMurdha?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 2 weeks ago

    Most systems trust a number of "root" CAs, including the one that signed the eMudhra certificate. It's possible LG TVs look specifically for a trusted LG certificate, but it's also very possible they use the same certificate stores as most major OSes/browsers.

  • source
  • parent
  • [–] 41 points 2 weeks ago (5 children)

    This plus the php thing and everything I was planning on doing today is out the window 😖

  • source
  • hideshow 5 child comments
  • [–] 40 points 2 weeks ago

    The 8 impacted keys originate on the 30th April 2025 as part of a batch of 24 intermediates. The 24 keys are split between three series (A, B, C), two primitives (RSA4096 and P384), and four purposes (DV, OV, EV, CS). The impacted keys are all the P384 keys for the B and C series. In May 2025 the A series were revoked and replaced by the A-1 series.

    After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.

    I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."

    Lmao

  • source
  • load more comments
    view more: next ›
    25 comments in c/technology@lemmy.ml view that post
    12 comments in c/linux@lemmy.ml view that post
    8 comments in c/linux@programming.dev view that post
    4 comments in c/technology@beehaw.org view that post
    3 comments in c/technology@lemmy.zip view that post
    1 comment in c/pulse_of_truth@infosec.pub view that post