The Internet goes on high alert after discovery of 8 compromised TLS certs
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://arstechnica.com/security/2026/10/the-internet-goes-on-high-alert-after-discovery-of-8-compromised-tls-certs/Open linkView original on lemmy.dbzer0.com
194 replies
That's amazing! I have the same combination on my luggage.
4, 8, 15, 16, 23, 42.
I'm lost.
That's what you get for going on the wrong plane
You've Skroobed up
I used to too.
Lottery!!
Sarcasm: Did you have the same lock for your underwear too pwr chance? Mine have sprouted legs.
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
Phew to think how close it is to my private key
And 8 of them no less. The guess of this being test code leaking into prod is likely, but security focused companies need consequences for stuff like this. That being said:
Looks like consequences to me...
that’s a very long way to spell the random number 4
::4
That kind of removes the bit size and hides it in assumption.
It's like winning the lottery
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.
is much more secure.
LOL, People are never gonna give this up.
I'm too lazy to do the math. Does that translate to the URL?
No, it is a string of text. "Never gonna give you up never gonna let you down"
ROFL, People are never gonna let this down.
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.
Ye, I'd struggle to believe ONE key getting generated like that, but 8 points to pure incompetence
Isn't every key equally unlikely?
Yes, be in is why having 8 of them total in the 2 digit range (I.e only using up to 6 bits of 384-bits) just screams incompetence of a hand generated key.
This plus the php thing and everything I was planning on doing today is out the window 😖
Why, what were you planning on doing that depended on these things?
I was planning on doing other work beside patching servers today.
Oh I get it, duh 😄
What's the PHP thing?
this https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html
LOL
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.
Newest release of Firefox Nightly on Android also still seems to connect.
I updated my Firefox today in the afternoon and afterwards it didn't connect.
I did try with Fennec from F-Droid, which was fine. I updated Nightly just now, and it does still connect.
Edit: Firefox Beta connects to 6/12 on https://emudhra.we-have-a-problem.com/
Edit 2: Regular Firefox connects to 0/12
Edit 3: Latest update fixed this in nightly, I haven't checked beta.
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 😓
Uhhhh as a dumb dumb Ubuntu user, do I need to do anything other than update?
Updating is all 😊 just need to make sure you have the latest CA-certificates package
Many thanks friend 😊
my Ubuntu 24.04 server is secured despite not updating anything or rebooting (I have now, but curl was already declining it before)
other issues would be software not respecting the system level certs, but that can happen on any OS, it just depends on the program
Lmao
Good thing my private keys are under a rock by my front door
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)
https://redlib.privacyredirect.com/r/Buttcoin/comments/1b1h34i/a_brief_glimpse_into_the_amazing_world_you_haters/
thanks :) need to bookmark some of these mirrors
I use untrackme on mobile, but I don't have anything of the sort on the desktop.
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.
My Firefox mobile got green ✅
Maybe try manually updating through the app store
In app safari on Mlem got all greens.
Mine showed red, but after updating it now shows all green
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.
Firefox can push certificate revocation updates without having to push a new browser build
https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/
I think cert updates happen automatically on their own without the browser needing to be updated.
what version are you on?
That one is on version 154.0, dated August.
Useful link, thanks.
Mobile Waterfox passes.
Interesting. I'm also using Waterfox and getting all red on my end.
Huh. I have version 1.2.8.1.
1.2.9 for me. Seems like I might have to revert to the older one.
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
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.
I'm using Firefox and that site says I'm good.
Yep, my Firefox mobile hasn't updated yet either, gonna see if there's an update I can grab.
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?
Odd my mobile Brave rejects all.
For mobile
6/120/12. Last updated 2026-10-17My Vanadium just refused all 12 connections. But maybe some of the DNS blocking or Suricata on my LAN might have helped.
Thanks, I tried harder and got the same result as you. Edited my comment above to reflect.
I just recently swapped to Fennec and it's correctly getting 0/12. These updates seem a bit inconsistent.
Ironfox is all green for me.
Cromite is half red, half green.
So yeah, fuck Chromium's monopoly.
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.
Update mobile Firefox it should be fixed now
I'm getting "⚠️ Inconclusive (timed out)" on Firefox 👀
Are you using a vpn/tor?
Do you mean not connecting to anything? Because that would be the action if you considered this a threat
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.
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?
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?
WDYM you're still using them all?
You don't have e any green ticks?
Brave Mobile is green ✅
⬆️ happy being on holidays
Oof. Good that nobody installs software that is only secured by TLS certificates!
I don't even know what TLS certificates are.
Okay, the other comment was actually pretty funny. But this one's a serious answer.
Transport Layer Security protocol is a way to share secrets. Basically, it's the lock on your airport luggage. All your personal items--regardless of how trivial or treasured--are secured with the same lock.
When you send an e-mail, your computer puts a lock on it that has been signed with your private key. It's sent to a recipient, who can unlock it with their own key. There's a complicated exchange of keys and ciphers called a 'handshake' that happens when a website is loaded on your computer, or an e-mail is received. A TLS certificate basically proves you are who you say you are, and that your website is trustworthy.
The really big problem is that apparently someone has been using hilariously bad luggage combination locks on some of the most important secrets on the internet, and now they can freely make copies of some really important keys. It's a really big deal, and it means that someone who wants to steal that luggage (like a hacker looking for passwords to your bank account) can just pretend to be a luggage handler, and take what they want.
* Communications, which could be you logging in into your banking account. The attacker would be able to see your banking password, for example. Or it could replace a software update your laptop is receiving with malware. A manipulated WLAN router in a cafe or an airport could do that.
This was the ELI5 version, and admittedly, network security isn't my strong suit. Thank you for the correction.
Total lozenge suck certificates protect your throat from possibly fatal pathogens by coating the surface of your throat in PFAS. Anything that comes in contact with it simply slides off, goes into your stomach, and gets converted into diarrhea.
Is this the OG poem for your sprig?
Omg!!
Definitely not. This one doesn't do poetry
That comment above is poetry.
Who?
Sprog.
Who's sprog?
Lol this guy doesn't know sprog.
It was a username on another site, a while ago. They wrote in poems. Nice stuff.
Someone has commandeered their name here on the fediverse; or so it seems.
tween that and PHP CVE, everyone is on fire ATM
It's the 00's all over again
Adversary-in-the-middle = man-in-the-middle?
perp-in-the-path
Yes, it's the same as mitm. I get that it's to avoid gendering the term but it doesn't really roll off the tongue or preserve the existing abbreviation. I've heard the alternatives: machine in the middle, mallory in the middle or, my favourite, Malcolm in the middle.
Less syllables is always gonna win, especially when it comes with alliteration
Just like main replaced master in a heartbeat.
Ticketmaster remains a notable holdout in that respect.
Menace in the middle
Molestor in the middle
Man is a gender neutral term
Only in some obsolete or deprecated contexts.
Monster in the middle is my fave
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?
It's commonly used and you often see the abbreviation AITM these days. You're right about the reason.
Good to know. Cheers.
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.
It's a term for the attack, yes but not for the attacker
So, all governments?
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
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.
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?
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.
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.
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.
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.
how would I get away from intermediary CAs? i also don't see indications eMurdha refused to fix the vulnerability when reported
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.
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.
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.
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.
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.
You lost me, none of that is true.
That's not what happened at all. Read the article.
if the keys are compromised, the CA is considered compromised until it is updated. from a black-box perspective this is not different from the CA's keys being leaked.
Not quite.
From: https://arstechnica.com/security/2026/10/hackers-obtain-counterfeit-tls-certificates-for-google-and-other-large-services/:
This did not happen like the verisign compromise, where someone posed as a Microsoft employee and got certs with Microsoft's name on them, which was a problem for all other Microsoft certs for servers and clients.
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
mightwill 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
A security model that depends on every random IOT device receiving timely firmware updates for its entire lifetime is not designed for the world we actually live in.
To be fair, revocation lists are public and you could check those on every connection. Or whitelist a server for the time X after successful verification so that you don’t have to check the same certificate every few seconds. But… that’s on the software you run. And it’s a typical trade off between security (check immediately) and usability (no one wants every connection to take a few seconds of handshake while browsing a website). And you need to think of this part of the security model. Guess how much thinking goes into security for many apps?
To be fair - those devices aren’t necessarily hacked because of this. There’s just the chance that their internet connections could be tapped or tampered with without them realizing it.
Thank you for the explanation!
Ok, so random networks (free WiFi) are even more risky, but what about mobile data networks? And is my home WiFi at risk? Is this an "update my router/modem" situation?
Second, what applications are at risk? Browsers are obvious, but most apps connect to the internet in some way. Is my lemmy app at risk? The local transit app? What about side loaded apps?
Also, are there any reasonable options for those eol devices? Assuming apps can be updated, what's the risk level for a device that's not receiving official updates anymore? Are there options or are the SoL?
Sorry for the deluge of questions. This is just confusing and concerning, and most comments I've seen are just jokes or assume a higher base of knowledge than most people have. Thanks for taking the time to break it down a bit better.
*Also, how legit is this site everyone is saying to check browsers on? Feels pretty sketchy to have a random site verifying safety in the middle of a situation like this.
First of all - DON'T PANIC
If you're not used to IT security, you always fall for the "Red Teaming" going on. Red Teaming means thinking of ways how a configuration, vulnerability, problem,... could(!) be used by the bad guys to proactively up your defenses. Or "guesstimate" how bad the situation will be. And you will always assume the worst case to be prepared. This usually always sounds and feels scarier than the reality is. Look back at my post and check if what I said contains ANY reference to how hard (or costly or time consuming) it'd probably be. Then add that nowadays many vulnerabilities are marketed for attention (or to also sell security products) - often with a fancy name, logo and website.
First of all: Nothing is risk free. You can just minimize the risks. And also many mitigations are a trade off between security and usability (or another dimension like affordability of new devices): Switch the device off, pull the plug and all connections to the external world and put it in a high security safe. Now you have an almost unhackable system - that you can't use anymore. And I'd still be able to find a (more or less unlikely) scenario how that device can get hacked...
Security usually relies on the "Swiss Cheese Model". Every security measure has holes like a slice of cheese. You can add more layers, but in the end there might still be some area uncovered by cheese. Here, we have several factors in play:
For this attack to succeed, I need to be in a position where I'm able to route ALL your traffic (that I'm interested in) through my box. The internet routes every package on an efficient way to the target, but theres no guarantee that all packets from the transmission take the same route. So it's not the best idea to put that box on a random point along the route. I need the whole transmisson. And then use these leaked keys to sneakily wiretap you (or alter the contents of the transmission). The two ideal positions would be the router that connects the network to the internet or the WiFi access point that you connected to. But this vulnerability (alone) should NOT be able to hack your router. You'd still need a way to get this set up on a router. One could use that to intercept the query for available updates from your router and send it a forged one, but usually those updates are also signed cryptographically and you'd need the key from it's vendor, too. And a specific software for your specific router. That's probably way too much work. I could also hack a server that you connect to, but then I wouldn't need those keys as I already control the server an can send you whatever I want (or read what you send me).
Also define "at risk": If someone can intercept your traffic AND use this forged certificate - WHAT can they gain? To "hack" the app and from there the device itself, they need another exploit in the app and send that to you. If you're logged in, they might be able to steal your credentials or your current session. But depending on the app - what is that worth? Your banking app probably features further security measures and is hopefully not affected. A transit app? They might buy some tickets (if they're even near you - they probably won't benefit from it)... Your Lemmy app? They might be able to use your credentials to access your account to send spam. But is that account worth something so that they can sell it or such?
Read: It depends on the app. And remember - it's company/developer/server could in theory be hacked (without these leaked keys, mind you) which yould bring you into the same situation.
IMHO: Someone found it and reported it. This might have been a honest mistake by that CA. Someone might have found that before and (ab)used it. It might have been found / a ruse by a state actor/"three letter agency" to have an easy way to wiretap people secretly. You cannot tell. BUT: If it's the latter - why would YOU specifically be targeted? And now that it's known it won't work anymore reliably - so it's burned. Why use it in the future? Especially if people might notice it easily?
For older devices this might have blown a few holes in a slice of cheese ("am I talking to the correct server?") and simplify other attacks a bit. But never forget: You cannot use this to access devices. You can only use that to tamper or wiretap with their network traffic if you're in the right place to do so without someone noticing.
First, thank you for the detailed response. I really appreciate it.
So from your explanation, I'm to understand that the risk here is just exposing sent data. Bad actors can't spoof these certificates to send bad data or malware to a device?
Correct. You initiate the connection TO a server and might get forged replies or have someone in the middle snooping on you. Usually (for personal use) there's no scenario where someone on the internet initiates a connection to you. Especially since every home router also features a firewall that by default declines all unsolicited incoming connections that weren't initiated FROM your network.
Also, even if you were to have devices on your network that can recieve such connections from the internet (e.g. a homeserver or some IoT device that configures your router to expose it ugh) this wouldn't allow attacks on the device itself, but still only affect its communication.
Basically this only allows attacks on the integrity and confidentiality of communication but does not attack a device or its software directly. You'd need further exploits for that (which might now be a bit easier to pull of as that one slice of cheese no features bigger holes).
Got it. That's reassuring. Thanks again for the explanations!
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?
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.
So this means, i shouldn't use my old android anymore?
With my 'security hat' on, I'd have to say you shouldn't use anything that's no longer receiving updates. But that would create a lot of e-waste for no reason.
To see if your phone's browser is still receiving updates, you can browse to:
https://emudhra.we-have-a-problem.com/
That has a grid showing whether your browser was willing to connect to sites using the compromised keys. If your browser is using its own cert style and still receiving updates, should be all green ticks. If so, then you can still use the phone for browsing internet. Be aware that using other apps on your phone (like eg. your email app) could be read easily by third parties, especially if you're connected to unfamiliar wifi.
If it's all red, maybe try another browser? Or relegate that device to being a dumb phone - switch off its data connection, phone calls only.
Depends. If the app uses cert pinning it will only trust the cert baked into it.
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.
Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.
Conceptually, I get it. Esepecially if you go with the 'DNS pinning of CA' to have a 'belt and suspenders' approach where two chains of authority must be broken, one of which inherently tied to your name.
Practically speaking, DNSSEC hasn't managed to get ubiquitous adoption. To the point where browsers started giving up and doing DNS over HTTPS to well known providers instead.
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.
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.
https://www.gnunet.org/
note: I understand none if this
After trying for a bit, I can certainly relate to understanding little of it. It's not as concretely explained as I would like and sticks to abstract principles. So no idea about the current state of affairs.
This is TLS, not SSL.
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.
Those were NSA backdoors.
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.
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.
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.
You're absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.
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.
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?
That should be possible yes, depending on how those TVs handle their cert stores.
wait how would that work? don't LG TVs use a random CA that likely isn't eMurdha?
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.
Thanks, I wasn't sure if it mattered that the leaked keys in this case were for intermediate certs and not root certs (afaik)
This news is scary and bad, but if the root keys ever leak, the Internet as we know it is fucked.
On grapheneOS, i just manually disabled the root CA's in the trusted root store.
These are all android versions on graphene:
*There are now 14 certs
AFFECTED:
Firefox (nightly),Ironfox, andfennec STILL connects to all 12Tor connects to 6 of themCromite 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
Ironfox as of 158.0.1 (Build #2016191578) is no longer affected.
Tor is fixed as of 15.0.26 (140.17.0esr) (Build #2016191530) Fennec all clear
My IronFox is clear as per https://emudhra.we-have-a-problem.com/
Same here
Fennec f-droid didn't connect to any on my test.
Tor is compromised? How do I check if my firefox or chrome has been compromised now?
I thought tor was impossible to decrypt for an attacker, but they can see you are using it.
It isn't that tor is compromised, it's the tls root CA, which can be used to create certs to look like valid site cert for any site.
Which basically means the internet is compromised until these (and God knows which other root authorities) are blocked and decertified.
Nice, that's handy
I've done this as well, but Fennec doesn't seem to care at all, and still happily connects, even after cache clears and a reboot. Fennec also ignored the about:config change another commenter suggested. Makes no sense. It's pissing me off.
Yep. Got updates from firefox, ironfox, fennec within past few.hours.
Firefox and ironfox have resolved issue.
Fennec still conmects to all 12
Fennec and other Firefox forks: Put
in address bar and search for
Toggle it to True
If your android cert store is good, you will be good for now. Test it
Why would this put vpn users at risk if browsers have already blocked the problematic certs?
it would put VPN users at risk if browsers had not blocked it or updated enough and the VPN provider chooses to do shenanigans, that’s why security patches patch the security and why it it’s important to patch this security issue
What, just because they are potential middle men?
yes, the VPN providers
VPN users use certificates to identify their servers. I assume then it’s not used by the VPN services?
arrgh. got to get off my lazy ass and do a thorough updating this weekend.
IronFox all green here
Regular Firefox, too
Waterfox on android is in the clear
Edit: Build info, just in case
1.2.8.1 (Build #2026380629)
GV: 156.0-20260922074625
AS: 156.0
OS: Android 16
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.
is AI karma-farming on Lemmy too now?