Most active commenters
  • tsimionescu(4)
  • amluto(3)

←back to thread

A Brazilian CA trusted only by Microsoft has issued a certificate for google.com

(follow.agwa.name)
482 points sanqui | 11 comments | 30 Nov 24 21:35 UTC | HN request time: 0.001s | source | bottom
Show context
danpalmer ◴[01 Dec 24 00:47 UTC] No.42285229[source]▶
This is a bad look. I expected the result would be Chrome and Firefox dropping trust for this CA, but they already don't trust this CA. Arguably, Microsoft/Windows trusting a CA that the other big players choose not to trust is an even worse look for Microsoft.
replies(8): >>42285389 #>>42285408 #>>42285431 #>>42285622 #>>42286061 #>>42286142 #>>42286897 #>>42287654 #
jsheard ◴[01 Dec 24 01:23 UTC] No.42285389[source]▶
What is even the point of a web CA that isn't trusted by all of the major players? Is there one?
replies(3): >>42285424 #>>42285444 #>>42285550 #
tialaramex ◴[01 Dec 24 01:36 UTC] No.42285444[source]▶
These are generally government CAs, so, typically the situation is Microsoft sold the government Windows, and as part of that deal (at least tacitly) agreed to the CA being trusted, and so every system that's trusting these certificates is a Windows PC anyway, running Edge because the whole point was the government will only use Windows and pays Microsoft $$$.

Why bake it into everybody else's Windows? If you make say a Brazil Government-only Windows which trusts this CA instead, I guarantee somebody crucial in Brazil will buy a 3rd party Windows laptop independently and it doesn't work with this CA's certificates and that ends up as Microsoft's problem to fix, so, easier to just have every Windows device trust the CA.

They'll have an assurance from the CA that it won't do this sort of crap, and that's enough, plausible deniability. Microsoft will say they take this "very seriously" and do nothing and it'll blow over. After all this stuff happened before and it'll happen again, and Windows will remain very popular.

replies(4): >>42285464 #>>42285561 #>>42285818 #>>42285942 #
amluto ◴[01 Dec 24 03:28 UTC] No.42285942{3}[source]▶
The solution seems straightforward: limit the trust in the CA to .BR domains.

[domain name typo fixed]

replies(2): >>42285957 #>>42286002 #
1. kelnos ◴[01 Dec 24 03:41 UTC] No.42286002{4}[source]▶
IIRC name constraints is very poorly supported by client software, so there are likely lots of clients out there that wouldn't even parse that restriction out of the cert, and happy accept anything singed by the CA.
replies(3): >>42286042 #>>42286555 #>>42290933 #
2. amluto ◴[01 Dec 24 03:51 UTC] No.42286042[source]▶
I’m not talking about a name constraint — that would need to be part of the root certificate. I’m suggesting that MS add a feature to its root store to constrain the usage of the certificates in the store. IIRC Google’s root store has features like this.
replies(1): >>42286979 #
3. 8organicbits ◴[01 Dec 24 06:05 UTC] No.42286555[source]▶
I think support for name constraints is much better now, but I think someone needs to correctly audit it. We need near universal adoption for it to be considered a usable tool.

I researched the issue a little here: https://alexsci.com/blog/name-non-constraint/

4. tsimionescu ◴[01 Dec 24 08:01 UTC] No.42286979[source]▶
The Windows trust store doesn't offer a verification API, I believe it simply lists the trusted certificates so that they can be looked up by verification software. That is, OpenSSL doesn't ask windows "hey, is this certificate with this chain trusted for google.com?" it asks Windows "hey, do you have a cert in the trusted root CAs with this ID? If so give it to me", and then OpenSSL will use that root cert to check if this is the real google.com.

Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services.

Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.

replies(1): >>42288755 #
5. nordsieck ◴[01 Dec 24 15:00 UTC] No.42288755{3}[source]▶
> Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain.

That's a silly position to take.

When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.

replies(1): >>42288962 #
6. tsimionescu ◴[01 Dec 24 15:44 UTC] No.42288962{4}[source]▶
It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
replies(1): >>42290581 #
7. amluto ◴[01 Dec 24 20:39 UTC] No.42290581{5}[source]▶
This is true, but it’s an old design that has been (in my opinion at least) obviously wrong since the very beginning of HTTPS. Microsoft could easily fix it, at least for clients that can manage to use an updated API.
replies(1): >>42293809 #
8. cvalka ◴[01 Dec 24 21:42 UTC] No.42290933[source]▶
As of 2024, they are well supported.
9. tsimionescu ◴[02 Dec 24 07:03 UTC] No.42293809{6}[source]▶
Microsoft has nowhere near the power to change the PKI and/or DNS. And it's not an API problem, it's a problem of where companies go to get their legitimate certs. If there are a lot of companies getting their certs for international TLDs from country CAs, or country TLDs from international CAs, then you have to wait for huge systemic changes before enforcing any kind of TLD-CA relationship.
replies(1): >>42297769 #
10. account42 ◴[02 Dec 24 16:33 UTC] No.42297769{7}[source]▶
Microsoft has absolute power about the restrictions they support in their root store.
replies(1): >>42300019 #
11. tsimionescu ◴[02 Dec 24 20:21 UTC] No.42300019{8}[source]▶
That's irrelevant. My whole point is that such restrictions go against the whole design of the PKI, at a systemic level. It's actively harmful to try to restrict trust in a CA to certificates for a certain TLD, because the two don't have any relationship whatsoever, by design.

It would be like restricting trust in a CA to certificates for sites whose name starts with a certain letter. It's exactly as meaningful from a Web PKI perspective.

Could Microsoft make it so that Windows only trusts this CA for certificates on domains whose name starts with a "b"? Sure. Would it help with anything? No. Would it be actively harmful to companies whose name starts with A that are using this CA? Yes. The same thing is true for domains whose name ends in .br.