Rendered at 09:55:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
agwa 3 hours ago [-]
https://gist.github.com/AGWA/5a78186e0f4a7d537b8891a7b46f945... is the list of certificates in Certificate Transparency issued by the blocked CAs as of this time. They appear to be non-malicious test certificates, and the DNS name in the first certificate indicates who likely discovered the issue.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)
FiloSottile 2 hours ago [-]
I did not discover the issue. I just wished to have a rapid and definitive way to test the patch(es).
amluto 58 minutes ago [-]
Am I off base, or should I be surprised that you were able to get the mentioned cert issued in the first place this recently (yesterday)? It seems unexpected that certificates are being actively issued and logged coming from a to-be-forcibly-distrusted part of the hierarchy.
The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on.
Was that cert issued via normal means (e.g. ACME)?
rollulus 1 hours ago [-]
I think that the Go project is lucky to have you. Thank you for what you do!
ericbarrett 6 hours ago [-]
A bit more info (and some discussion linked from these Bugzilla reports):
It is a shame that you cannot have a cert signed by multiple CAs.
(The format seems like it would allow it, but nothing supports it, and in practice CAs demand the ability to actually modify some fields, and then sign that.)
crote 5 hours ago [-]
It is done with intermediate certs, though! It's a common method of establishing trust in new root certs: sign the intermediate with an already-trusted root cert, then wait for the community to adopt the new root cert over the years.
For example, the initial Let's Encrypt Authority X3 was signed by both their own (new, not-yet-universally-trusted) ISRG Root X1, and the universally-trusted third-party IdenTrust DST Root CA X3.
One crucial detail is that it isn't the same certificate. Rather, it is two separate certificates which just so happen to be using the same key pair, so the leaf cert is in essence signed by both intermediate certs at once.
I wonder if it would be possible to do the same thing on your own, actually: can a server present two completely separate cert chains to a connecting client - as long as the leaves use the same key pair? Technically AFAIK the only requirements should be 1) the key pair in use for the connection matches the cert, 2) the domain matches the cert's Subject, and 3) the cert is trusted, so at first glance it might be possible...
GoblinSlayer 2 hours ago [-]
AFAIK, that's what google does: it sends a second post-quantum chain in addition to ecc chain.
shame it wasn't adopted. rent seeking CAs would never go for it.
hannob 1 hours ago [-]
Every time there is a CA issue, someone comes up with "this would be so much better if we'd make it more complex than it already is, as it would make it a bit more convenient to deal with the most recent issue".
I don't think that's the right way to think about it.
cpach 4 hours ago [-]
Would it really be worth the extra complexity?
Another option: Use ACME together with ARI (RFC 9773). The client checks ARI data every hour. If the cert needs to be replaced – for example like in this scenario – the CA will inform the client, which in turn would then request a new cert.
I know it’s not convenient to automate for every kind of device though. I guess in some of those cases it might be better to have a load balancer in front of the device. Or use an alternative PKI.
Puts 2 hours ago [-]
I think certificates should be like badges that you can collect – the more badges the higher the trust. So if you are a French company, maybe the tax office in France can sign your certificate to show that you indeed is a real company. If you are accepting card payments – Visa and Mastercard could sign your certificate. If you have a domain the TLD owner could sign your certificate to show that it's indeed your domain… And so on…
And then the browser could present these badges in a nice way to the user.
calgoo 2 hours ago [-]
I just worry that this would just bring us back to the: "Pay $$$$$$ for a certificate, those pesky lets encrypt free certs are not expensive enough to give trust", BS that always happens.
LoganDark 2 hours ago [-]
Imagining those little "Intel Inside" "AMD Athlon" "Windows Vista" style stickers all over my browser address bar
And then you have that one website trying to collect them all.
lmz 5 hours ago [-]
X.509v3 just has one issuer Name in the certificate, unless you're talking about something else?
wnoise 5 hours ago [-]
Yeah, that's one of the complications. It would have to be ignored in processing, or multiple variants be presented at once (preferred).
Certificates are not the same as the public key; multiple certs sharing the same key is essentially the way around this. It's not as elegant as identical signing of the same cert, but it could work.
crote 5 hours ago [-]
Identical signing of the same cert also runs into issues like "who gets to decide the serial number" and "how to deal with revocation lists: all of, or any of?".
And turning fields like issuer and serial into arrays risks someone accidentally using index 0 for one field and index 1 for another.
Combine that with the insane back-and-forth nightmare that the issuance process would turn into, and I have a very hard time seeing the benefit in it. After all, nobody is stopping you from requesting multiple certs independently, watching the revocation logs, and switching to the backup when required.
accountrequired 5 hours ago [-]
"Sir, this is a Wendy's" moment where my compiler thought it was a root certificate authority
TheDong 4 hours ago [-]
I mean, they're the TLS certs are baked into the stdlib 'tls' package, not the compiler itself.
It's just an unfortunate unforced error that the go TLS package is bundled along with the compiler, in the same way Safari being bundled with iOS updates is an unforced error meaning a safari security bug requires a full OS update.
rollulus 3 hours ago [-]
There are no certs baked into Go’s stdlib. This is about pkg x509 blacklisting certain certs that get loaded from elsewhere.
TheDong 23 minutes ago [-]
Oh, wow, that makes it even sillier. If I want to delete certs from my system certificate store, I can do that, the stdlib should not be making that choice if it's not even packaging the things.
It's interesting that this sort of policy is baked into a language platform.
Jarred 55 minutes ago [-]
If you don't bundle certificates, users will report that your builtin https client doesn't work in production (usually in docker)
computerfriend 20 minutes ago [-]
This is already the case for Go.
zx8080 2 hours ago [-]
It's probably about power. Certs control is getting higher value, so control over this policy means more negotiation power with whatever states (governments) need from platforms.
It's easy to imagine something like: "give us some grant taxpayers money and we'll add your cert to our trusted list/remove theirs cert/disable cert when run on this hardware/etc."
fractorial 5 hours ago [-]
What about it makes it so interesting?
jeffbee 5 hours ago [-]
Clearly the platform isn't designed to do this. Nobody thought this was going to be a necessary facility. They have just crammed an array of numbers as literal values deep into the standard library. So clearly this is an exceptional event, and not the exercise of a feature that was foreseen.
zx8080 2 hours ago [-]
One of those "temporary workarounds" that live forever once added?
fractorial 5 hours ago [-]
Ah, yes that seems to be what URGENT track self-documents as.
stephbook 5 hours ago [-]
Indeed. But the Java keystore and the Firefox/Chrome/VSCode NSSDB and whatever Python is shipping this week aren't really better.
I wonder what's so annoying about OS certs.
quiet35 2 hours ago [-]
I really appreciate Firefox to have their own certificate DB because it allows to create separate profiles with different trusted certificate sets. The country where I live issued it's own root certificates which I have reasons not to trust in all cases but when accessing government services etc. So I've created a separate Firefox profile where I've installed those malicious certificates, keeping the main Firefox profile clean.
fc417fc802 44 minutes ago [-]
It's nice that firefox implemented that but it's the wrong place to do it IMO. It's the sort of thing that should be built into the OS along with fine grained permissions and sandboxing. The browser is merely providing a bandaid over a deficiency.
whatevaa 5 hours ago [-]
It's mostly historical. They used to suck in the past, but the implementations remain. Nowadays you are better off configuring to use OS certificates if possible.
What's alarming and unprecedented is that yesterday, two Certificate Transparency log implementations were updated to block the logging of certificates issued by the CAs. This likely indicates total private key compromise, and the blocking by CT logs is to prevent the logs from being spammed by forged certificates. However, it also means there will be no place to record forged certificates found in the wild. (These certificates won't validate in CT-enforcing clients since they won't be in CT logs, but could be used to attack non-CT-enforcing clients.)
The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on.
Was that cert issued via normal means (e.g. ACME)?
https://bugzilla.mozilla.org/show_bug.cgi?id=2083709
https://bugzilla.mozilla.org/show_bug.cgi?id=2018979
(The format seems like it would allow it, but nothing supports it, and in practice CAs demand the ability to actually modify some fields, and then sign that.)
For example, the initial Let's Encrypt Authority X3 was signed by both their own (new, not-yet-universally-trusted) ISRG Root X1, and the universally-trusted third-party IdenTrust DST Root CA X3.
One crucial detail is that it isn't the same certificate. Rather, it is two separate certificates which just so happen to be using the same key pair, so the leaf cert is in essence signed by both intermediate certs at once.
I wonder if it would be possible to do the same thing on your own, actually: can a server present two completely separate cert chains to a connecting client - as long as the leaves use the same key pair? Technically AFAIK the only requirements should be 1) the key pair in use for the connection matches the cert, 2) the domain matches the cert's Subject, and 3) the cert is trusted, so at first glance it might be possible...
shame it wasn't adopted. rent seeking CAs would never go for it.
I don't think that's the right way to think about it.
Another option: Use ACME together with ARI (RFC 9773). The client checks ARI data every hour. If the cert needs to be replaced – for example like in this scenario – the CA will inform the client, which in turn would then request a new cert.
I know it’s not convenient to automate for every kind of device though. I guess in some of those cases it might be better to have a load balancer in front of the device. Or use an alternative PKI.
And then the browser could present these badges in a nice way to the user.
And then you have that one website trying to collect them all.
Certificates are not the same as the public key; multiple certs sharing the same key is essentially the way around this. It's not as elegant as identical signing of the same cert, but it could work.
And turning fields like issuer and serial into arrays risks someone accidentally using index 0 for one field and index 1 for another.
Combine that with the insane back-and-forth nightmare that the issuance process would turn into, and I have a very hard time seeing the benefit in it. After all, nobody is stopping you from requesting multiple certs independently, watching the revocation logs, and switching to the backup when required.
It's just an unfortunate unforced error that the go TLS package is bundled along with the compiler, in the same way Safari being bundled with iOS updates is an unforced error meaning a safari security bug requires a full OS update.
data from https://www.ccadb.org/resources
It's easy to imagine something like: "give us some grant taxpayers money and we'll add your cert to our trusted list/remove theirs cert/disable cert when run on this hardware/etc."
I wonder what's so annoying about OS certs.