CAA checking becomes mandatory for SSL/TLS certificates | Hacker News Reader

CAA checking becomes mandatory for SSL/TLS certificates

ma.ttias.be

70 pointsMojah32 comments

I think people in here are misunderstanding the threat model this is protecting against, which is probably because the article doesn't really explain it.

This is not to protect against malicious CAs. You'd need DNSSEC for that, but that's just pushing the job down to the next turtle below you, since DNSSEC needs certificates and trust too.

This is to protect against malicious operators from getting CAs to give them certificates without authorization of the domain owner. The reason this is necessary is because the method that CAs use to validate that they're issuing the certificate to the right person is not standardized, and so you end up with a bunch of potential ways that an operator could fraudulently get a certificate that are hard to stop. I know in the past, some CAs would issue to certificates to anyone with root@, admin@, or any one of a list of privileged email addresses. Do you want email admins to be able to create whatever certificates they want for your domain? No.

> This is to protect against malicious operators from getting CAs to give them certificates without authorization of the domain owner. The reason this is necessary is because the method that CAs use to validate that they're issuing the certificate to the right person is not standardized, and so you end up with a bunch of potential ways that an operator could fraudulently get a certificate that are hard to stop. I know in the past, some CAs would issue to certificates to anyone with root@, admin@, or any one of a list of privileged email addresses. Do you want email admins to be able to create whatever certificates they want for your domain? No.

I don't see how CAA protects against this. If you're using CAA, presumably your email admin could just request a certificate from one of the whitelisted CAs. The only saving factor is if your whitelisted CAs don't support email-based verification.

You already have a relationship with the whitelisted CAs and they know who the correct points of contact are.

The standard also makes it possible to add CA specific limitations. The RFC shows as example how you could setup the record do that CA will only serve requests for specific customer account.

Since there's quite much competition on the field, I would assume CAs will be eager to implement these kind of value add services.

There is at least one CA that simply doesn't offer DV. So if you happen to agree with them that DV is worthless (for the record I do not), or at least that it's never appropriate for your business, then setting CAA to require that CA means nobody will be using some scheme to get "legitimate" DV certificates for your domain.

If I understand correctly, you could set this to 'CAA 0 issue "example.org"' effectively preventing conforming CAs from issuing certificates for your domain. Then if you actually need to get a new cert for the domain, you would temporarily switch the value to your certificate provider of choice.

The standard way to do that is:

    example.com. CAA 0 issue ";"

https://tools.ietf.org/html/rfc6844#section-5.2

...in September 2017, according to the linked article. Title might need a little tweak to reflect that fact.

Last I checked route 53 did not support caa records yet. Any idea when they might be a available?

See also this great gist on CAA adoption:

https://gist.github.com/roycewilliams/1710ade469c05eb0b090d2...

There was a little discussion on this topic yesterday:

https://news.ycombinator.com/item?id=14068901 (12 comments)

There seem to be very little benefit to this new validation check. The CAs I've used have required you to prove you have control over the domain you want a certificate for (either by adding a DNS entry or by responding to an email sent to one of the defined contacts in the registry.

If someone can already create a new DNS entry for you, they can create their own CAA entry. If someone has compromised your registry account, they can always redirect DNS requests for your site to a new location.

You have it backwards. The point of this is so that a CA does not issue a certificate to someone who does not have control of your DNS records. It's a fail safe.

Plus combining this with Certificate Transparency should allow for handling this in an automated fashion. A third party can validate CAs to ensure compliance.

  A third party can validate CAs to ensure compliance.

Domain owners can remove or change the CAA record after the certificate has been issued - so any third parties performing checking will have to be quick about it :)

Well you would want it to be quick anyway right? I don't want to know about a shady cert issuance next month, I'd want to know now!

Why would they? The idea of CAA is to help the domain owner, to prevent malicious issued certificates, to have a documented, open, visible way do identify which CA is authorised to issue a certificate. So, if you doubt what you see is legitimate, you have a way to check (also, when combined with DNSSEC, it is quite hard to forge/spoof).

Even without DNSSEC, every little bit of additional validation counts IMHO. You could e.g. trace sudden changes in CAA records and get very suspicious...

It's quite hard to forge or spoof to anyone except:

* The world governments that control the TLDs and can thus override DNSSEC policy by fiat.

* Any attacker between the CA's resolver and the DNS server, since DNSSEC only protects transations between DNS servers, not between clients and servers.

I would hope CAs run their own DNSSEC validating resolvers, and they don't just plug "nameserver 8.8.8.8" into resolv.conf.

Appart from DNS many CAs do web or email based checks. And those had quite a few vulnerabilities in the past, e.g. in the extraction of whois records (via OCR...) [1] or through markup injection in the validation emails [2]. CAA can prevent misissuance in such cases.

Having an extra safety layer around these is definitely useful. It's not a super strong measurement like HPKP and CT, but still I think CAA is a useful extra security mechanism in the CA ecosystem.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1311713 [2] https://thehackerblog.com/keeping-positive-obtaining-arbitra...

I think github.io is a good example of where this can be very useful. Users have a lot of control over the content of their pages, but it is undesirable to allow them to get a cert for username.github.io. Previously the only defense would be to block all files or content that could be used for domain validation or specific blacklisting by all CAs. Now GitHub can just say "no one can generate certs for this domain".

What does CAA protect against? Malicious/pwned CAs can issue certificates anyways. Unless browsers start enforcing CAA correctness, this doesn't seem to be very useful. Browsers checking the CAA record seems like it would be an OCSP-like situation where browsers don't do the check to avoid a performance penalty, or softfail when they get no response.

I'm not sure it "protects" anything, per se - more of a formalisation that CAs should verify that the domain owner is the one making the request.

I doubt browsers will ever check CAA, since it's even easier to tamper with than OCSP (since the majority of DNS requests are still over plain text).

Take Facebook's experience last year as an example

Facebook has this policy where all the facebook.com and fb.com certificates, including sub-domains, test sites, everything, have to go through a central security team. Obviously they can't reach out to every CA in the world and tell them about this policy and the millions like it at every company. So they came to agreement with a single CA, and only ever use that one CA who knows their rules.

A company working with Facebook built some site, let's call it example.fb.com. They were responsible for it, so they controlled the content on the site. Some employee at the contractor wanted an SSL certificate, they'd heard of Let's Encrypt, so they just used Let's Encrypt to get themselves a certificate. Let's Encrypt checked their proof of control, it was fine, so it issued a certificate to the employee.

Now, within 24hours that certificate was published to the Certificate Transparency system, and Facebook's security team monitors CT, so they saw there's this certificate for example.fb.com which is from this new Let's Encrypt service not their usual CA and they didn't ask for it. They, understandably, go straight to alert status - possible attack in progress.

In that particular case it ends happily, the firm making example.fb.com confesses to what happened, that they didn't read the terms telling them to get certificates from Facebook security, the certificates are revoked, it's not Let's Encrypt's fault this happened, CT logs are proved to do the intended job...

But CAA allows Facebook to tell everybody "Digicert is the only CA we want issuing for our names" and not have this whole panic in the first place. With CAA in place, Let's Encrypt would have told that employee "Issuing for this name is forbidden due to CAA" and then the employee would look that up on Google, realise they just violated Facebook's policy and reach out to Facebook Security. No sirens, maybe somebody gets a slap on the wrist, life goes on.

Cloudflare hasn't even mentioned adding that record type

It's apparently "in the works" (https://twitter.com/eastdakota/status/820376781320519680 and https://twitter.com/grittygrease/status/820378094901096450)

We are doing it right now.

So only CAs check this, not browsers?

Surely the problem this sort of thing is meant to address is rogue CAs who are already behaving badly.

That's correct. Browsers offer other mechanisms like HPKP to mitigate attacks through rogue CAs.

Active CAA checks by browsers would either be soft-fail like OCSP (i.e. useless in the face of an active adversary who could block the request or spoof the response) or cause a lot of unnecessary warnings because of failed requests. You'd also have to force every site on earth to create a CAA record if you want it to be hard-fail. That's going to be impossible.

Not really, no. CAA addresses the problem where you'd like to actively tell a trustworthy CA not to issue for your names.

The Facebook incident I've mentioned further up is a good example.

But CAA is fully dependent on DNS(Sec).

Why would that be the case? Can't I have untrusted records indicating you can't do something (issue a cert for a domain)? That's how SPF / DKIM works.

At worst you'd get false rejections which you'd follow up on immediately as your cert wouldn't be issued.

Sort of an idiotic way to do this considering you can use the DNS infrastructure to validate the actual certificate and get rid of CAAs altogether. Chain of trust then goes from the owner of the website directly to his or her readers rather than some private organization which by its very nature is already compromised to third parties like the government.

Thankfully, you're still allowed to not have any CAA record for a domain. While I agree that in general it's a good thing, for my setup, the additional security it provides is not worth the hassle of upgrading PowerDNS past what comes with the OS (Debian 8 ships with 3.4.1, CAA requires 4.0.0).

Generally, I notice that the pace of standards requiring newer versions of software than what's shipping with the latest OS releases is increasingly quicker these days.

Like ALPN being required for HTTP/2 and not being supported by the latest stable version of Debian.

Reply on news.ycombinator.com