There were no certificates from the compromised intermediates logged to CT prior to remediation by the browsers.

CT is great for browsers. Largely irrelevant for anything being fetched outside of a browser.

There are plenty of ways you would never be able to tell if a fake cert had been generated and used via this attack vector (let's ignore validation attacks):

1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.

2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice

3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts

4. Non-Browsers do not validate SCTs

Not all TLS traffic involves a browser.

I believe Android updates things like CA certs independently of their monthly security patch. I'm not sure Android 12 uses the same system, but on newer Android I think those are shipped via Google Play system updates, which don't require waiting for the phone vendor.

None of the roots were compromised. (Some of) Their own sub-CAs for TLS certs, which are also cross-signed by Sectigo (since their own roots are rather recent), are affected.

How you have that root cert on your phone with a 3 year old CA set I have no idea, presumably something updated your CAs in the meantime? (Also, aren't you incredibly exposed to the general onslaught of vulnerabilities from the past 3 years?)

To be clear, emSign is another name for EMudhra, and Comodo is now known as Sectigo. (You can't just look at the organization name in a certificate subject; you have to consult the CCADB: https://www.agwa.name/blog/post/the_certificate_issuer_field...)

They used the "correct" key for signing the CRLs (which of course was then an invalid signature):

> The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.

And THAT is where I'm drawing the line between "honest mistake" and "gross negligence". For that to not raise giant red flags is an unacceptable failure in process and work culture.

> Windows will happily run unsigned binaries

This is absolutely false, it's a simple policy change to enforce code signing, any organization that is serious about security can do it.

I'll give you the benefit of the doubt and assume you're another Linux guy who doesn't understand Windows security.

The concern of course is with malware being signed, which is far more likely to be abused than some TLS MITM fantasy.

The most likely explanation is that they generated the weak key externally, imported it into the HSM, generated the CSR from it, and finally had Root CA sign it.

A FIPS HSM does not forbid one to import keys into it.

My vague and inexperienced read on their description boils down to "we were doing something weird and non-standard as part of our key ceremony because we intended these keys to be exported, and because of that process weirdness we blundered and gave the HSM faulty instructions."

Y'know… let's just check…

https://ctlogs.io/search?mode=fingerprint&q=42c4accd12c4f595...

https://ctlogs.dev/search?q=42C4ACCD12C4F59597925E1A08A7A901...

https://ctlogs.io/search?q=EBED6475C2C2D80FCB199F3FE8DD6E6B3...

https://ctlogs.dev/search?q=EBED6475C2C2D80FCB199F3FE8DD6E6B...

Nothing for "CN=EM DV TLS CA - G3B,O=eMudhra BV" (not sure which sha256 this uses, 2nd is the spki sha256)

I should be clear here my understanding is/was these are sub-CAs. Apparently they're (trying to be?) roots themselves? The point of logging a root cert in CT is somewhat moot… though tbh I would argue anything issued by a CA should be in CT logs, even cross-signing another CA that is becoming a root itself.

If you're doing a MITM attack, you can selectively intercept certain clients, and only serve the compromised certificate in those cases only. Automated scanners won't pick that up. None of this actually works though, because browsers started mandating certificate transparency.

In the most extreme case, you can just issue a certificate and not use it anywhere. If it leaks, it's still a security issue, because it's valid.

More realistically, especially with sub-CAs, they might only be used on e.g. corporate networks. TLS scanners may not be able to reach any of the hosts that uses such a cert. As the sibling post points out, clients checking for the cert in Certificate Transparency logs counters that (adding a requirement that the cert be publicly known, which TLS/X509 by itself very much does not have) — but of course this only helps if your client does CT…

It's not within the realm of believability. The chance of "human screwed up" astronomically exceeds this being fairly randomly chosen, and the Firefox bug states, (I think this is supposition, not known fact, but IDK)

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

That is within the realm of believability.

When you have multiple selections you can show that the probability of selecting a set with a range much smaller than the population range is exponentially unlikely, strong evidence to reject the hypothesis that the subset was chosen at random. But when N=1 you can't conclude anything.

Yep, but it was an easy zero-touch MITM vector for billions of devices that's only now being closed down

In any case, not much sovereignty to gain from only 8 bits :^(

Ok, now do that same paragraph, but for drive-by RCE vulnerabilities.

Nobody thinks this is a good thing. It's bad. Hopefully, eMudhra gets distrusted. We've done that to bigger CAs.

Didn't Let's Encrypt have to jump through all sorts of hoops to prove they were competent and trustworthy before that happened?

Now it's coming out these guys used "4" as a private key. That's a crazy amount of incompetence and malfeasance. Did they vibe-code a CA? HOW DOES THIS HAPPEN? I am dumbfounded.

You couldn't even do this if you installed Microsoft Small Business Server 2008 today, unpatched, with the CA on default settings.

> But that's not something we can really save in the Web PKI's current state.

I agree with your assessment but it's not an excuse to give up without trying. I hope this is just because I'm not looking in the right places, but I don't see people trying.

What really makes me salty is that there was enough energy to mess with the rules around EKU, the primary effect of which is that non-browser software is now starting to just ignore the EKU bits. Even if it would've amounted to nothing, I'd really rather that effort had gone into NCs.

If you mean Comodo and Setigo, they're the same company, pre- and post-rename.

Let's just say they've had issues with signing sub-CAs before where those sub-CAs went on to misuse them before… looks like it was around 2011?

It's uncommon on Windows for applications to use a third party certificate verification library because Windows provides an API that does it. On Linux, you have no choice because all the platform provides is a bundle of PEM certificates.

Web of trust has been working between humans for over a million years. If we've failed to make computers do it, it's probably just for lack of trying.

To your second point, that might be true in a world where the consequences of making a bad trust decision was some kind of hassle related to changing passwords or reporting your cards stolen. But we seem to be moving towards a world where it lands you in a detention facility or some other dire consequence. I think that sooner or later, users are going to realize that they want that control and will be willing to do the corresponding trust hygiene work. Besides, isn't making that kind of work easy the point of technology? We just need to do better re: making it usable rather than investing in systems we know to be unsafe.

The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.

Name constraints are intended for organizations which want to issue publicly-trusted certificates for their own domains. Name constraints are already widely supported and name constrained sub-CAs exist for this purpose in the WebPKI.

eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.

[1] https://incommon.org/certificates

I like constraints too, but listen carefully to EKR and 'agwa on this, because a lot of things that seem like straightforward fixes are much more complicated in reality. The most important thing I want from the WebPKI is expensive entry and the death penalty for fuckups, and I think we basically have that now.

Do the words "no discernible reason" just mean something very different to you than they do to me? Because I've written somewhere in the vicinity of 100,000 words about the problems of DNSSEC over the last 20 years. My written DNSSEC critique predates HN itself.

This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.

Rare in public PKIs, yes; not so much in private ones, I would imagine.

From my limited experience (using them at home) they seem to be fairly well supported in client libraries, actually!

- OpenSSL has full support, https://docs.openssl.org/master/man5/x509v3_config/

- GnuTLS has full support, https://www.gnutls.org/manual/html_node/X509-certificate-API...

- go (crypto/x509) supports everything except DirectoryName constraints, https://pkg.go.dev/crypto/x509#Certificate.Verify

- Python (pyca/cryptography) has full support, https://cryptography.io/en/stable/x509/reference/#cryptograp...

- Windows/Schannel has full support, https://learn.microsoft.com/en-us/windows/win32/seccertenrol...

- Java has full support, https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

- I know that NSS also supports them from experience but (sorry!) couldn't find the docs in a few seconds of searching

- I know that Strongswan supports them well because I actually opened an issue about it a few years back and got it fixed :-)

(Just a few off the top of my head)

> and half the world that does pin is probably pinned to Let's Encrypt

To be fair, unless I'm misunderstanding, wouldn't this be a good move?

LE has a good security record and takes itself seriously, versus these smaller CAs that seem to mess up regularly.

You can pin in software you distribute. If you're big enough (top 100 websites mostly), you can ask browsers to pin certs and they may included it in their preloads.

> And what happens when you want to switch?

You have to update your pins and then wait long enough that you don't mind losing users who never update their software. When it's just in software you distribute, you can change hostnames in new versions and use the new CA for new versions and the old CA for old versions...

For web browsers, there's not a reasonable way to make a nicer transition. You have to serve old certs for old pins, and TLS handshakes from browsers don't include enough information to know if the client has an old pin or a new pin; or at least, mostly they don't --- if you get your pins changed and the browser TLS stack changes so the handshake changes after that, maybe you can use that... when sha1 certs were phased out, it was somewhat popular on high volume sites to look at the TLS Client Hello to decide to serve a sha256 cert or a sha1 cert.

DNS CAA only pins issuance, not acceptance; clients can not check if the CA that issued a cert was listed in DNS CAA at the time of issuance, and they do not check if it's listed at time of presentation. I'm pretty sure issuing a cert contrary to a CAA record is a mississuance and would result in sanctions from the CA/Browser forum, but clients would still accept the cert until it's revoked.

https://kagi.com/search?q=dns+CAA CAA is one way, but you can also pin the actual certificate or certificate chain (which has its downsides, mind you).

Because it makes you only as secure as the the LEAST secure CA. Such as the really bad ones that don't use Hardware Security Modules.

I'm not making an argument for a single centrally-managed trust store. The thing that seems most obviously bad to me here, as a non-crypto-expert, is that any CA can issue a certificate for any domain. This is probably made worse because there are hundreds of CAs, and AFAICT functionally every trust store trusts all of the same ones.

I don't know how we fix this, but it does seem like a big problem.

> The design intent is still bad though: we should never have given CAs universal issuance privileges.

This is sort of right and sort of wrong. It's true that you could have a DNSSEC-style regime where only one entity could issue for a given domain, but as long as you're going to allow third party issuance at all, then you have to contend with the fact that most CAs want to issue in the big gTLDs (.com, .org, etc.) and so narrowing issuance doesn't help that much in many cases.

> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

This is ahistorical. By the time that DANE was designed, the WebPKI model was well entrenched and there was a huge population of browsers that couldn't really be upgraded and also only supported the WebPKI. If you wanted something that was acceptable to those browsers, it had to be WebPKI and it had to be cross-signed, hence Let's Encrypt.

I suppose you could argue that at some point after that one could have tried to deploy DANE and phase out LE and the rest of the WebPKI. I don't think that's true for the reasons that have been discussed on HN about DNSSEC, but that's really not the same as you wouldn't have needed LE in the first place.

> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

Had we been using DANE instead of WebPKI, the response to this sort of compromise would be "aw, shucks, someone proved to be untrustworthy and they're in such a critical role in the ecosystem that there's no way to route around this DNS provider being untrustworthy."