4 ms·

The solution seems straightforward: limit the trust in the CA to .BR domains. [domain name typo fixed]

by amluto 2y ago

bitwize 2y ago
.bz is the TLD for Belize. Brazil is .br.
kelnos 2y ago
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.
- amluto 2y ago
  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.
  - tsimionescu 2y ago
    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.
    - nordsieck 2y ago
      > 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.
      - tsimionescu 2y ago
        It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
        amluto 2y ago
        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.
        tsimionescu 2y ago
        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.
        account42 2y ago
        Microsoft has absolute power about the restrictions they support in their root store.
        tsimionescu 2y ago
- 8organicbits 2y ago
  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/ https://alexsci.com/blog/name-non-constraint/
- cvalka 2y ago
  As of 2024, they are well supported.

The solution seems straightforward: limit the trust in the CA to .BR domains. [domain name typo fixed]

by amluto 2y ago

The solution seems straightforward: limit the trust in the CA to .BR domains. [domain name typo fixed]

bitwize 2y ago

.bz is the TLD for Belize. Brazil is .br.

kelnos 2y ago

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.

amluto 2y ago
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.
- tsimionescu 2y ago
  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.
  - nordsieck 2y ago
    > 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.
    - tsimionescu 2y ago
      It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
      - amluto 2y ago
        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.
        tsimionescu 2y ago
        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.
        account42 2y ago
        Microsoft has absolute power about the restrictions they support in their root store.
        tsimionescu 2y ago
8organicbits 2y ago
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/ https://alexsci.com/blog/name-non-constraint/
cvalka 2y ago
As of 2024, they are well supported.