At some point you’re forced to stack rank two or more of your values in a case where they’re mutually exclusive

So, not trusting anything wireless is a thing for almost a decade.

But the broader threat, e.g. older & unpatched devices with these flimsy CAs installed & not upgradable or revocable – tough cookies.

In fact, it's securing _the companies_ against potential competitors and users who might raise privacy concerns

The Fortune 500 "MiTM's" TLS traffic from their local networks

Every individual with a local network should also be doing this

I prefer haproxy to mitmproxy. It's faster

If you’re proxying all the traffic in your network it makes sense, naturally. mitmproxy is usually used for debugging and/or reverse engineering (e.g. with a specific app).

I prefer Lua to Python. It's smaller and startup time is faster

https://web.archive.org/web/20261029130824/https://alignment...

I would be amazed to see a TV that is checking CRLs and keeps the CRLs up to date.

I think they deserve more than 8 bits of infamy.

https://news.ycombinator.com/item?id=50185797

>I'm in the process of reshaping my game dev career to avoid contributing to this kind of rot. Don't mind eating noodles if that's what it takes.

So how is your game dev career going? Why don't you share some links to the game you're working on, its designs, code, and demos, so we can understand exactly what you mean, and then you can explain just what kind of rot you're so offended by, and what your answer to it is, once you've finished eating your noodles?

Here's an old demo I recorded years ago -- do you have any demos of your own anti-woke homophobic game to share, or even other successful anti-woke homophobic games you want to emulate, that prove your point?

https://www.youtube.com/watch?v=-exdu4ETscs

Can't you defend your angry frustrated bigoted accusations that activist developers like me ruined games and broke up teams like The Sims, which has made well over $5 billion for EA? I'm really looking forward to reading your designs, watching your demos, and reading your reply to my post that directly addresses your accusations and counters them with evidence and receipts here:

https://news.ycombinator.com/item?id=50188638

Yet you and maxlin are still clinging to and defending its bigoted long disproven ideas, as if it's core to your personality.

So you're the deranged out of touch ones, decades behind the times, and on the wrong side of history, unable to counter my arguments or EA's $5 billion in sales with any evidence at all. You're just bigoted GamerGate armchair vibe game designers, with lots of hot air but nothing to show.

Edit: Your "slandering innocent people into suicide" is pure psychological projection from a bigot defending doxing and harassing women.

Thanks for proving my point by pulling evidence-free hallucinations and vibes out of your ass that can't counter $5 billion of evidence you're wrong.

Actually it was $5 billion 7 years ago, and a lot more now. So name a more successful homophobic anti-woke title.

https://en.wikipedia.org/wiki/The_Sims#Legacy

>Legacy: The success of The Sims has resulted in Guinness World Records awarding the series numerous world records, including, as of 2017, "Most Expansion Packs for a Videogame Series" and "Best Selling PC Game Series", with sales estimates ranging from 36 to 50 million units. The series ranks 10th among the best-selling video game franchises of all times, with a sales figure of over 200 million combining all the entries in the series. As of October 2019, all The Sims games combined generated lifetime sales of more than US$5 billion.

Edit: Still no evidence, huh? How much has your brand of indecently un-entertaining game design made? Name a title.

Edit: Yet again, still no evidence, and no rebuttal of my evidence, huh?

Let's look at your actual accusation:

akimbostrawman> If the "right side" is slandering innocent people into suicide for calling out blatant corruption, then i am fine with being wrong.

There was no corruption to call out. GamerGate started with an ex-boyfriend's blog post claiming Zoë Quinn traded sex for a favorable review from Kotaku's Nathan Grayson. Grayson never reviewed her game. Kotaku checked, and said so at the time. The "ethics in games journalism" scandal was a review that never existed:

https://en.wikipedia.org/wiki/Gamergate

What did happen was real: GamerGaters posted Quinn's home address and nude photos of her and drove her out of her home. They published Brianna Wu's address and sent her death and rape threats until she and her husband fled their home. Anita Sarkeesian had to cancel a talk at Utah State University after an email promised "the deadliest school shooting in American history." That's what the "right side" was doing in 2014.

The "innocent person slandered into suicide" you're alluding to is Alec Holowka, who died in 2019, five years after GamerGate, days after Quinn accused him of abuse. His own sister Eileen said he had been a victim of abuse, and also wrote "I will not pretend that he was not also responsible for causing harm." And she explicitly asked people like you:

"Alec specifically said he wished the best for Zoë and everyone else, so don't use our grief as an excuse to harass people."

https://www.pcgamesn.com/alec-holowka-death

So you're using a dead man's suicide as a weapon against the woman GamerGate already doxxed and drove from her home, against the explicit wishes of his own grieving family. You're spreading corruption and hate, not calling it out. That's GamerGate's playbook, seven years later, from someone still desperately clinging to it like a deranged little boy.

If the "right side" is slandering innocent people into suicide for calling out blatant corruption, then i am fine with being wrong.

Edit: rewriting your post with more and more nonsensical claims while decently entertaining is what i expect.

Edit2: I never claimed to have made games but i guess just daring to disagree with your world view warrants genetic fallacies, false allegations and insults, once again what i expected.

I was gonna ignore your further ignorant remarks however this is too disgusting to not reply to. I do not need the permission from anybody to mention my own experiences just because they got bullied into silence and accepting similarly unhinged behaviour to finally have there peace.

Woke is cringe, it's a settled matter, calm down buddy.

server: here are latest ads

btw, the ads are capable of code execution for whatever reason so now you have an RCE on your hands for your client

Anyone else bother to notice iOS still trusts 2 of the forged certs on the test site? I'd like to politely know what the fuck is going on because this is far from being "fixed".

I've just been rechecking everything and both iOS and MacOS browsers (Safari and Orion tested) now accept one (for MacOS, 27.0.1) or three (for iOS, 27.0.1) of them. I know the revocation is not an OS update, just including the version number for completeness.

EDIT: iPadOS with the same browsers continues to pass the tests.

Further EDIT: iPadOS now accepts one of them. This has to be a load issue on the "got a problem site", surely? Maybe a check for a certificate error message that never hits because a timeout beats it?

No, because it lets you successfully navigate to the forged CA test site.

You'll get a message to the effect of, "you shouldn't see this, this is bad"

Try clicking the link containing the CA's name for any that fail the test.

Checking Keychain access shows none of the intermediates, but it does have the emSign ECC Root CA - G3. Manually setting that to "Never Trust" stops the Mac browsers seeing the intermediate test sites as it should.

I didn't go into this much detail this morning, so I don't know if previously the revocation from Apple hit the root as well as the intermediates. But right now, on my Mac, trusting that Root lets my browsers connect to the Intermediate CA ending C=NL. Switch the trust off and I go back to green "Did not connect".

I guess the ball is in Apple's court as far as the iOS family goes.

EDIT: intriguingly (to me at least), the AAA Certificate Service Root is still Trusted, yet the intermediates chained to it are all green "Did not connect"

EDIT: I'm not promoting this nuclear option as a "solution" by the way, merely presenting some diagnostic information to help the group mind.

I don’t know if possible on iOS but I remember multiple incidents where people recommended turning off CRL and OCSP on macOS to speed things up. That even used to be a setting in the GUI. https://imgur.com/XVHWCNz

It's possible the Indian CA is overloaded.

My question is why the system trust store has not been updated to distrust the shady root CA?

Edit: I'm not the only one with this issue:

https://www.reddit.com/r/iphone/comments/1xbvxgd/emudhra_cer...

My best guess is it's soft-failing on a failed OCSP lookup?

https://tech-insider.org/emudhra-ca-private-keys-compromised...

(Credit to the relevant xkcd. :D )

https://security-tracker.debian.org/tracker/CVE-2008-0166

https://lists.debian.org/debian-security-announce/2008/msg00...

The xkcd was 2007 [0], the Debian issue was 2008 [1].

It was used in pretty much every blogpost describing the Debian issue, but it wasn't created because of the Debian issue (unless they gave Randall an 8-month head-start before disclosing it).

(I don't mean this as a "well akshully" - but for me it's more impressive that it's a truism that keeps coming true, than if it was just a swipe at them in the first place)

[0] https://web.archive.org/web/20070930232116/https://xkcd.com/...

[1] https://lists.debian.org/debian-security-announce/2008/msg00...

Here's how the famous "Debian Weak Keys" come into existence:

OpenSSL had two buffers we care about here for generating random keys, with associated code to mix from those buffers into the data that's going to finally be used to produce cryptographically random numbers, lets call these bufferA, bufferB and mixA, mixB

In some cases bufferA is intialized by reading data from somewhere, in other cases it was never initialized. So mixA is doing uninitialized reads in those other cases. OpenSSL is written in C and in principle reading uninitialized data is Undefined Behaviour in C, but in practice nothing terrible happened here, you'd probably get zeroes, in some cases maybe unrelated trash. However, tools for spotting UB in your C library kept flagging mixA, which read this uninitialized data, as a problem.

bufferB is always crucial, if this isn't used the numbers won't be very random at all. This data is always initialized. But mixB is very similar code to mixA, after all it is doing similar work.

OpenSSL had rejected work to "fix" the mixA uninitialized bug but a Debian developer decided that it was too annoying so they patched mixA out. If that had been the whole story nothing terrible happens and nobody would remember today. However since mixB is similar, that Debian developer asked the OpenSSL developer list hey, is it OK to patch out mixB too?

And the developers said it was OK. The result is that Debian shipped OpenSSL which did not actually generate truly random keys. There were some number (thousands?) likely and of those a handful were especially most likely to be picked, based on exactly how soon after system start you wanted to make some keys with OpenSSL.

Now, after this blew up those developers said they thought the question was about testing. And IIRC it was possible to look at the same email and, if you know mixB is crucial, you think obviously they just want to test that their change does what they expected, nobody would patch out mixB in production, that's crazy. But the developer who wrote the email intended a different meaning, they really did mean to patch out mixB and were asking if that's OK.

That's as clear an explanation about the situation as I have ever read. I don't know the occasion to need to explain it to anyone else will arise, but when it does... or I may use it as example of the consequences of shallow communication when serious outcomes may arise. (Ill be sure to credit the source 'tialaramex' on HN)

Train driver and signaller both believe they've reached the same understanding of the situation, but their understanding actually remains divergent, and the driver (plus a MOM) nearly gets killed as a result.

            MD_Update(&m,buf,j);

Also, while I'm not sure what a "mudhra" is, I do know that mudra is a Hindu term for a sign or symbol made by the hands, for example the way an idol is posed in a temple. It's a form of sacred sign language. Therefore, "mudra" or its related term is intrinsically linked to Hinduism in India.

Also, I am the kind of pessimist who goes through my device's root stores, and I "distrust" every root CA that I don't need to trust. This has never broken anything within my perception. I distrust the Turkey CAs, the Chinese communist CAs, the Indian CAs, and any other non-NATO sorts who have no reason to be serving any data to my devices.

* the compromised eMudhra certs were not root CAs but intermediates.

> On October 17, 2026, browser root programs received a report that the private keys of eight eMudhra intermediate certificates had been compromised. The private keys were 4, 56, 66, 115, 155, 156, 230, and 237. A P-384 elliptic-curve private key normally has about 384 bits of entropy, but these keys had between 3 and 8 bits.

(While the smallest one being 4 memeworthy, I don't see any particular indication that it's exceptional within the samples, rather than just the smallest when sorted. So they're probably all 8-bit keys, not 3-bit—it's the (unknowable) generator distribution, not the width of the actual key).

So from the perspective of hacking old IoT devices, if your device hasn't been updated since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.

I object to the word compromised. Perhaps "available" or "enumerated" or maybe for the etymologists "unipromised".

It was a particularly poor choice of number, but still

I was mainly interested in testing which IoT devices are affected and protecting them, not trying to sniff their traffic since it's been a long day. My proxy thus just intercepted and forwarded the traffic upstream using a fresh TLS connection that does not use the compromised keys.

Release is out now, including a blog post at https://www.mitmproxy.org/posts/releases/mitmproxy-12.3/. There isn't really much to explain, you just pass `--emudhra`. :)

[0] https://news.ycombinator.com/item?id=50190859

That was my broken sense of humor. The memes around it have been golden.

which brings me to my next question, what if you rerun the same process for all the certificates in the "approved" stores, give them 1 min per certificate.. just to see how many other CAs are being "friendly" to parties that could take benefit of that...

update... I'm talking out of ignorance here... but assuming cli open source tools, should they prevent you creating certificates with weak settings unless --emudhra-level-security is passed?

also, what amount of time is needed in say a "civilian" gpu with claude to vibe code something that can test a certificate so say 80 bits.. or whatever is the level where yes, you cannot find the values to generate the certificate with a cpu... but you can with a gpu in say 1 day? say it's 80 bits... how many CA stores are there? how much does it cost to rent gpus to run in parallel to test 1 day of civilian gpu to check each certificate if you use one of these very expensive ones?

Versus: "The government ordered us to give them the keys and forced us to remain silent about it" - now all the damage lies on the government, who is likely known to already do stuff like that (or at least it isn't a surprise) and will hide behind the banner of safety or national security or something. (Whether it's true or not)

Per AI, 10²¹ years

Alternatively I would presume you could do it in 1 year with 10²¹ GPUs.

Being bad at choosing random numbers is not a crime, I am afraid.

I can imagine them being sued for "securities fraud" (as Matt Levine suggests) but only if they were a US publicly traded company.

Your MCU likely escaped the eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50183280 - Oct 2026 (24 comments)

Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds - https://news.ycombinator.com/item?id=50177916 - Oct 2026 (411 comments)

eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (478 comments)

Probably would have been better to call it "compromised" or something like that.

https://en.wikipedia.org/wiki/Illegal_number