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. }

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    16
    ·
    7 hours 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

  • Blackmist@feddit.uk
    link
    fedilink
    English
    arrow-up
    59
    ·
    11 hours ago

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

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

  • Limonene@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    ·
    8 hours ago

    Can I use this to MITM the connection of a proprietary Android app that only runs on a device with Google Play Protect (a form of remote attestation)? And then reverse engineer the API?

    • addie@feddit.uk
      link
      fedilink
      English
      arrow-up
      16
      ·
      7 hours ago

      Assuming that the device hasn’t been updated yet, yeah, this is what it allows you to do.

      If you connect your device to a ‘fake’ router that’s completely under your control, then when the device attempts to connect to its remote server, you pretend to be it, and provide a certificate signed by this ‘trusted’ authority. Device will accept it. Make another connection to the real remote server. Decrypt what the device sends you, and send it on to the remote server; it’ll believe that you’re the android device, and respond with a message that you can decrypt, store, reencrypt with your fake key, and send it to the device. Repeat.

      You’ll only be able to impersonate the API until the keys are revoked by an update. That’s maybe not so useful. However, any other connection that can be MITM’d and include other personal information - your bank card details, say - can be read, too.

  • Die4Ever@retrolemmy.com
    link
    fedilink
    English
    arrow-up
    95
    arrow-down
    1
    ·
    18 hours ago

    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

    • Fontasia@feddit.nl
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      6 hours ago

      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 😓

      • Die4Ever@retrolemmy.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        5 hours 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

    • notthebees@reddthat.com
      link
      fedilink
      English
      arrow-up
      12
      ·
      9 hours ago

      Edge on windows 11 also did it. At least as of last night. My debian boxes are up to date and they have been fixed.

  • thisbenzingring@lemmy.today
    link
    fedilink
    English
    arrow-up
    213
    ·
    edit-2
    21 hours ago

    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

    • mlg@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 hours ago

      Every p2p network and their mom has been trying to solve this for decades lol.

      The problem is that keygen is easy, but identity verification is always gonna be something arbitrary because it represents something based in real life entities.

      Even with TLS, people only trust google.com as being Google because they learned that Google uses google.com.

      I could make a goggle.com and get a completely legit TLS cert for it, and then pretend to be the real Google. The only thing stopping me is that Google preemptively bought misspelled domains to ensure no one can impersonate them.

      The lazy solution already exists. Just don’t use PKI and use direct trust on first connect like SSH.

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      ·
      13 hours ago

      Ok, but what would that look like in a way that would have mitigated this situation? Seems likely that such a system could actually exacerbate this specific scenario.

      • mschae@discuss.mschae23.de
        link
        fedilink
        English
        arrow-up
        5
        ·
        13 hours ago

        Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.

        • The_Decryptor@aussie.zone
          link
          fedilink
          English
          arrow-up
          3
          ·
          10 hours ago

          As nice as DANE is, it just shifts the burden of trust to your DNS provider. Like if you hop on Wi-Fi at a coffee shop, said network can simply MITM connections and supply their own certs via re-writing the DNS.

          You can encrypt DNS to prevent that, but now you need a way to ensure your DNS client already trusts the desired DNS server, etc.

          As much as people dislike CAs, they’re a proven solution to a problem that’s already implemented in nearly every device on the planet.

          • mschae@discuss.mschae23.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            10 hours ago

            As nice as DANE is, it just shifts the burden of trust to your DNS provider. Like if you hop on Wi-Fi at a coffee shop, said network can simply MITM connections and supply their own certs via re-writing the DNS.

            It can’t, because DANE requires the use of DNSSEC. Unfortunately, there are still so many domains that do not have a proper DNSSEC configuration… so it’s unlikely to work out well in practice, anyway.

            edit: not to mention the DNS is centralized too. It’s federated, at least (in the original sense of the word, not the way it is used on the fediverse), but ICANN is still the only central authority at the end.

  • joey_builds@eviltoast.org
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    11
    ·
    6 hours ago

    The wildest part to me is that the keys weren’t just weak, they were tiny — 4, 56, 66 — small enough to fit in a byte. That’s not degraded entropy, that’s a keygen path that returned a counter or a placeholder value instead of randomness at all. And since the public halves of those certs have been sitting in Certificate Transparency logs for years, anyone could’ve caught it by just testing small scalars against the published public keys — no nation-state budget needed to find them, only to quietly use them. The browser response was genuinely fast once it surfaced, but this was detectable the whole time. Makes you wonder how many other CAs have test values live in production that nobody’s ever bothered to scan for.

  • Zarobi@aussie.zone
    link
    fedilink
    English
    arrow-up
    41
    arrow-down
    1
    ·
    20 hours ago

    First: Who the fuck is eMudhra?

    Second: What catastrophic failure of process allows a single point of failure Indian company to compromise the entire internet as we know it by accidentally releasing debug code? Why is it so fragile in the first place?

    • Aatube@lemmy.dbzer0.comOP
      link
      fedilink
      English
      arrow-up
      32
      arrow-down
      1
      ·
      18 hours ago

      eMudhra is an intermediary certificate authority. some of the most popular intermediary CAs* are Sectigo, GlobalSign, MilesWeb, and GeoTrust. would you \^_^/ like to tell me who the heck ✨ these✨ are?

      HTTPS has always had a failsafe called certificate revocation. it is working. at least, until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason

      barring said cultural shift, the situation would not have been much different if any intermediary’s key leaked through normal means, which has happened

      * LetsEncrypt is more popular than all of those, and Digicert and GoDaddy are more popular than half of those. But that’s where the name recognition ends.

      • calcopiritus@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        9 hours ago

        There is no reasonable way to be an ethical hacker when the companies you are hacking are not ethical themselves.

        If they refuse to pay bounty programs, and refuse to fix the security vulnerabilities, there’s just no way to do security research.

        If you don’t wanna get hit by security issues, get as far away as possible from these companies.

        • Aatube@lemmy.dbzer0.comOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          7 hours ago

          how would I get away from intermediary CAs? i also don’t see indications eMurdha refused to fix the vulnerability when reported

          • calcopiritus@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            4 hours ago

            I didn’t say it’s easy. It’s just the only way. First step would be removing them from the list of trusted CAs installed on your devices.

            And of course, security flaws chain together. So if you don’t trust Microsoft office, you basically can’t trust any commercial product in existence.

            But at least you can avoid being a direct customer of them, even if you’re still an indirect one.

    • non_burglar@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      ·
      19 hours ago

      It is a problem we all have with dns, namely that the way it works now means we all must trust upstream CAs.

      And unfortunately, we will probably suffer a few more of these before we switch over to a voting peer system.

      • hirihit640@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        2
        ·
        17 hours ago

        DNS requires consensus (on who owns which name). So if by “voting peer system” you are talking about decentralized consensus, then blockchain is one of the only systems of such kind.

        If you don’t want blockchain, then there’s no real choice other than a centralized system like CAs.

        • non_burglar@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 hours ago

          Eh, blockchain wouldn’t work here because changes to the ledger on the scale of DNS would take an astronomical amount of time to propagate. Blockchain would solve “source of truth” issues, but waiting 30 seconds or more every to.e you open your browser or curl to update the list of changes to the CRL wouldn’t be an acceptable working solution.

          The problem of “voting peers” I mentioned would more easily be solved by a mechanism closer to how clusters decide which members are reliable and which should be deemed faulty. The problem is to instantly make changes to the CRL that are believable and take effect immediately.

          Blockchain can’t do that in a timely way.

          • hirihit640@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 hours ago

            how clusters decide which members are reliable and which should be deemed faulty.

            I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work. After all, the issue at hand is a compromised CA.

            • non_burglar@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              11 hours ago

              I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work.

              You lost me, none of that is true.

              After all, the issue at hand is a compromised CA.

              That’s not what happened at all. Read the article.

  • Illogicalbit@lemmy.world
    link
    fedilink
    English
    arrow-up
    57
    arrow-down
    1
    ·
    22 hours ago

    At this early stage, the most immediate threat appears to be for those using VPNs, especially in countries with governments likely to maliciously intercept traffic.

    So, all governments?

    • PotatoesFall@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      4
      ·
      12 hours ago

      I’m confused, doesn’t a VPN help protect against mitm in public networks? Are you saying that governments might use this at VPN exit nodes? That actually makes sense

      • nanometer1625@thelemmy.club
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        10 hours ago

        For VPNs to be vulnerable, the VPN provider’s internal traffic must flow through an MITM server before exiting the VPN provider’s internal network. VPN providers don’t have any specific weakness or flaw that would would make an MITM attack easier to execute, but it is definitely true that a VPN provider would be a high-value target for such an attacker, both because a large volume of traffic flows through the VPN provider, and also because people who use a VPN provider are more likely to be doing so because they are doing things that their government wouldn’t approve of.

  • BluescreenOfDeath@lemmy.world
    link
    fedilink
    English
    arrow-up
    151
    ·
    1 day ago

    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.

    • KeenFlame@feddit.nu
      link
      fedilink
      English
      arrow-up
      1
      ·
      13 hours ago

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

      • BluescreenOfDeath@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        11 hours ago

        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.

        • KeenFlame@feddit.nu
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 hours ago

          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?

          • BluescreenOfDeath@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            10 hours 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?

      • Aatube@lemmy.dbzer0.comOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        23 hours ago

        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

        • tuckerm@feddit.online
          link
          fedilink
          English
          arrow-up
          3
          ·
          18 hours ago

          It’s displaying fine for me, I think I was just scrolling quickly on my phone and didn’t notice that the https://emudhra.we-have-a-problem.com/ link in the body was different from the linked article. I saw a blockquote in the post body, and figured that the URL beneath the quote was a link to the article.

    • bazzett@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      20 hours ago

      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?

    • cheeseburger@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      24 hours ago

      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.
      • floofloof@lemmy.ca
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        24 hours ago

        My Vanadium just refused all 12 connections. But maybe some of the DNS blocking or Suricata on my LAN might have helped.

        • cheeseburger@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          ·
          24 hours ago

          Thanks, I tried harder and got the same result as you. Edited my comment above to reflect.

      • IronKrill@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        23 hours ago

        I just recently swapped to Fennec and it’s correctly getting 0/12. These updates seem a bit inconsistent.

    • ArgentRaven@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 day ago

      I’m on a 10/7 build and I’m vulnerable on mobile FireFox, as well.

      Edit: updated to a 10/19 version, 158.0.1, and it’s still vulnerable.