1. 9

  2. 2

    This is why any service that cares even slightly about security should:

    • Use DNSSEC
    • Set CCA records.

    I’d love to see web browsers start warning if these conditions are not both met. Setting CCA records means that someone who compromises e-Turga or any of the other probably insecure CAs can sign a cert for your domain, but clients know not to trust it (assuming that they do CCA checks). Without DNSSEC, an attacker needs to be able to also compromise DNS responses, which is easier than compromising a CA, but requires a more targeted attack on the client. With both, this kind of problem affects only customers of e-Turga.

    Of course, once you have both of these, it’s not really clear why you need a CA at all. If you have DNSSEC then you can just publish a TLSA record containing your public key and avoid the need for a cert chain at all. You only need your TLS certificate to be signed by a third party if you want some claim stronger than ‘the owner of this domain name is also the owner of the computer that you are talking to’ and, now that EV certs are not given special treatment by browsers (because CAs were terrible at validating the claims that they signed), there isn’t really any expectation of this in most use (and the places that do this typically use private signing certs and do their own validation).

    With CCA and a CA-signed key, anyone who compromises your DNS server can change the CCA record and replace your cert with one signed by another CA (which can be Let’s Encrypt, because ACME2 allows anyone who can update DNS records for your domain to issue certs). It also allows anyone who compromises your CA to issue certs for your domain. They might be caught if you’re actively monitoring certificate transparency logs. With TLSA, anyone who compromises your DNS can replace your public key and create a fake certificate for you and will show up only in CT logs recorded by clients (CAs are supposed to publish keys to CT logs, but if you’re a malicious actor who has compromised a CA, then you probably won’t), so CA + CCA records introduces more points of failure than TLSA but leaves you vulnerable to the same attacks.

    Unfortunately, I don’t think any of the major browsers support trusting unsigned certs via TLSA.

    1. 2

      CAA cannot be checked in the browser. They are a method to indicate whether a CA is allowed to issue certs for your domain - at the point in time when the certificate is issued. But a browser cannot retroactively check what CAA record was set at the time a cert was issued.

      If a browser would check that a CAA record matches the issuer of a cert then a situation like this could occur: A site owner decides to switch the CA for the next cert renewal. Old cert is CA X, new is CA Y. The site owner configures the CAA record for the domain of CA Y. However he still uses the cert from CA X for a transition period as long as it’s still valid. That’s legit and not forbidden by anything in CAA, but your browser would reject it.

      There’s another more subtle reason why browsers can’t check CAA records: What do you do if you can’t fetch the CAA record? (e.g. you get a SERVFAIL or DENIED or the DNS does not answer.) Do you assume an attack? Or do you assume it’s an old resolver that has no knowledge of the CAA record type and does not forward queries with unknown DNS types? As a CA controlling your own DNS resolver you can make sure that it understands CAA records, but as a browser you cannot do that, as you have to assume all kinds of DNS resolvers in cheap routers etc. that you need to stay compatible with.

      1. 1

        I thought CCA records are only checked by the CAs themselves, upon certificate creation?

        1. 1

          They definitely can be checked in the client. I believe Chrome does. They provide no value over ACME2 if not.

          1. 4

            CAA records are explicitly not allowed to be checked in the client (since they don’t affect existing certificates retroactively). They’re a layer of swiss cheese for buggy CAs, that’s all.

            The way to delegate trust strongly via DNS would indeed be DANE, but it seems unlikely Chrome will support it; they have offered various reasons, but trying to read between the lines, I think they place a lot of value on their ability to strongarm CAs into meeting new requirements they come up with. I don’t like this at all, but given there are still TLDs that don’t support DNSSEC, I think relying on Google to bully CAs is probably slightly safer than relying on ICANN to bully NICs.

            1. 1

              I don’t like this at all, but given there are still TLDs that don’t support DNSSEC, I think relying on Google to bully CAs is probably slightly safer than relying on ICANN to bully NICs.

              Presumably Google could also bully NICs into accepting whatever security standards they wanted (like DNSSEC, stronger cryptography for DNSSEC, …), lest the domain names under their administration stop working (or show some fat ugly warnings) in Chrome? Which would lead to domain owners complaining to their registrars and NICs.

      2. 2

        This is exactly my concern wrt “Sigstore” making itself clear as day