Intermediate certs allow anyone to mint web credentials for any Internet server.

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

  • thisbenzingring@lemmy.todayEnglish
    2091·
    10 days 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

  • BluescreenOfDeath@lemmy.worldEnglish
    148·
    10 days 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.

  • Die4Ever@retrolemmy.comEnglish
    851·
    10 days 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

    • notthebees@reddthat.comEnglish
      111·
      10 days 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.

    • Fontasia@feddit.nlEnglish
      4·
      10 days 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 😓

  • Blackmist@feddit.ukEnglish
    63·
    10 days ago

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

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

  • Illogicalbit@lemmy.worldEnglish
    551·
    10 days 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.deEnglish
      3·
      10 days 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.clubEnglish
        4·
        10 days 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.

  • superglue@lemmy.dbzer0.comEnglish
    42·
    10 days ago

    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.

    • Badabinski@kbin.earth
      15·
      10 days ago

      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.

      • BlueKey@fedia.io
        9·
        10 days ago

        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.

        • Badabinski@kbin.earth
          9·
          10 days ago

          You’re absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.

    • frongt@lemmy.zipEnglish
      31·
      10 days ago

      Yup.

      These days, a lot of firmware blobs are also signed with the vendor’s key, so you’d still need to get past that hurdle.

    • hirihit640@sh.itjust.worksEnglish
      1·
      10 days ago

      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?

      • x00z@lemmy.worldEnglish
        2·
        10 days ago

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

        • hirihit640@sh.itjust.worksEnglish
          1·
          10 days ago

          Thanks, I wasn’t sure if it mattered that the leaked keys in this case were for intermediate certs and not root certs (afaik)

  • Zarobi@aussie.zoneEnglish
    401·
    10 days 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.comOPEnglish
      281·
      10 days 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.

      • Elvith Ma'for@feddit.orgEnglish
        35·
        10 days ago

        until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason

        Basically they learned that if they told the vendors and kept their mouth shut, many vendors won’t do shit and will just ignore the problem. Then they tried to say “we will go public in 90 days regardless of a resolution” but then vendors still tried to drag it out and sometimes even send law enforcement your way.

        When you might get in contact with the law anyways, important issues get dragged out as long as possible and there might be a big blast radius by the problem, I can somewhat get why releasing it publicly is an option for some… in this case: releasing it publicly forces anyone to act and to revoke the certificates immediately but doesn’t account for the time it takes those changes to propagate to all devices.

        • Jako302@feddit.orgEnglish
          24·
          10 days ago

          What’s worse is that half the time people actively tried to tell vendors they got hit with a lawsuit in return. It usually doesn’t stick, but the sheer fact that you have to defend yourself in court cause you tried to help is nuts.

      • calcopiritus@lemmy.worldEnglish
        5·
        10 days 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.

    • non_burglar@lemmy.worldEnglish
      10·
      10 days 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.worksEnglish
        32·
        10 days 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.worldEnglish
          1·
          10 days 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.worksEnglish
            1·
            10 days 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.worldEnglish
              1·
              10 days 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.

    • Elvith Ma'for@feddit.orgEnglish
      101·
      10 days ago

      Warning, some oversimplifications ahead. Yes been warned.

      First: It’s a certificate authority. It’s job is to issue the certificates needed for TLS (formerly SSL) to persons and companies so that you can use their services with an encrypted connection instead of plaintext.

      Second: What exactly is the problem here? In the internet (or networking in general) your data passes a whole lot of “relays” before it reaches your destination. Everyone might will snoop on this (see e.g. the Snowden leaks). So you have a desire: “Don’t talk unencrypted to random servers!”

      This now has two dimensions:

      First: Don’t talk unencrypted to random servers.
      Nowadays everything knows how to do this. You just start shouting random numbers at each other and then both know the same secret secret key although it was never mentioned. Then you use that key to encrypt the communication.

      Second: Don’t talk unencrypted to random servers.
      This one is harder. You resolved the server name to an IP and connected there. But… Was your connection intercepted? Were you told the correct IP? Who exactly are you talking with? This is where this incident gets scary: The server presents you a certificate (basically an id card, drivers license,…) telling you who it is. This certificate has been issued by a certificate authority (CA) that validated at least that this server belongs to the domain you’re trying to connect to (maybe more, e.g. the company running it,…). You do not trust this certificate alone, but your computer knows how to prove with some maths that it was really issued by a trusted CA it knows. If everything is alright, start the communication.

      Scary: If one of those CA loses their key, anyone can issue certificates in their name. And everyone will trust those, as they seem genuine.

      What that means is, that if I know their key (which has just been published), I can now intercept any traffic running through my machine, say that I’d be the server you want to talk to and now I can see everything. And all you’d see would be the padlock in the address bar telling you the connection is safe and trusted. And I can serve you anything. I could use that to just read everything and note your passwords or serve you a phishing site instead.

      On a small scale, I would not be able to do much harm. I could set up an open WiFi at a cafe and get random people using that. But that’d be very localized and little effect. But since everyone can do this? Now every free wifi is potentially dangerous. You hack Starbucks and their customer wifi? Congratulations - you’re now doing this on a global scale! You hack an ISP? You can now fuck all their customers. Your a nation state actor? Well, have fun!

      How can we defend against that?

      Certificates can and will be revoked. They already are. In theory, everything is fine as no device with an up to date CA list will continue to trust those connections and will stop connecting. But it takes time to update all those lists. Your desktop running Windows, Mac or Linux? The update is probably already available. Your browser? Probably also already has the update available. But other devices? Your old EOL android tablet? The hand-me-down smartphones your kids got? Your smart home appliances that never got an update since you bought them 3 years ago?

      Also there are more defenses - not everyone is using them, as they also may have some downsides:

      DNSSEC - you can prove the IP is correct (assuming not this certificate was forged, too)

      Certificate pinning - you can tell clients on their connections, that only this one specific certificate will be in use for the next days/weeks/months. Every forged certificate will then be declined (but also your new certificate because you had to unexpectedly renew it). Or at least say “All certificates for this server are issued only by Lets Encrypt. For every connection from now on: Don’t trust any other certificates even if they’re completely valid”

      And a few more

    • khannie@lemmy.worldEnglish
      9·
      10 days ago

      First time I’ve come across the phrase but it sounds like the same thing. It’s gender neutral though I guess. Maybe that’s it?

      • PetteriPano@lemmy.worldEnglish
        7·
        10 days ago

        We had one compulsory course in English at university. The professor corrected a “man-in-the-middle” I had in a field-specific paper. She preferred “middle man”. She did buy that it was an established term in cryptography, though.

  • masterofn001@lemmy.caEnglish
    34·
    10 days ago

    On grapheneOS, i just manually disabled the root CA’s in the trusted root store.

    These are all android versions on graphene:

    AFFECTED:
    Firefox (nightly) ,Ironfox, and fennec connects to all 12
    Tor connects to 6 of them
    Cromite is still affected by 6 of them.

    NOT affected:
    Vanadium is not affected
    Vivaldi is not affected
    WebLibre (a firefox fork) is not affected
    Firefox nightly just received an update : build 2016191538 which rejects all 12

  • mlg@lemmy.worldEnglish
    29·
    10 days 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

    • jj4211@lemmy.worldEnglish
      12·
      10 days 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.deEnglish
        3·
        10 days ago

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

        • The_Decryptor@aussie.zoneEnglish
          3·
          10 days 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.deEnglish
            2·
            10 days 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.

    • mlg@lemmy.worldEnglish
      2·
      10 days 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.