6 ms·

CAA checking becomes mandatory for SSL/TLS certificates

70 points by Mojah 10y ago

okket 10y ago
See also this great gist on CAA adoption: https://gist.github.com/roycewilliams/1710ade469c05eb0b090d268470aa741 https://gist.github.com/roycewilliams/1710ade469c05eb0b090d2... There was a little discussion on this topic yesterday: https://news.ycombinator.com/item?id=14068901 https://news.ycombinator.com/item?id=14068901 (12 comments)
pilif 10y ago
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.
methou 10y ago
But CAA is fully dependent on DNS(Sec).
- koolba 10y ago
  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.
devoply 10y ago
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.
tallanvor 10y ago
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.
- koolba 10y ago
  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.
  - michaelt 10y ago
    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 :)
    - koolba 10y ago
      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!
    - okket 10y ago
      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...
davidgerard 10y ago
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.
- pfg 10y ago
  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.
- tialaramex 10y ago
  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.
kelnage 10y ago
...in September 2017, according to the linked article. Title might need a little tweak to reflect that fact.
homero 10y ago
Cloudflare hasn't even mentioned adding that record type
- jffry 10y ago
  It's apparently "in the works" (https://twitter.com/eastdakota/status/820376781320519680 https://twitter.com/eastdakota/status/820376781320519680 and https://twitter.com/grittygrease/status/820378094901096450 https://twitter.com/grittygrease/status/820378094901096450)
- jgrahamc 10y ago
  We are doing it right now.
  - deleted 10y ago
    [deleted]
discreditable 10y ago
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.
- kelnage 10y ago
  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).
- tialaramex 10y ago
  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.
klodolph 10y ago
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.
- discreditable 10y ago
  > 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.
  - klodolph 10y ago
    You already have a relationship with the whitelisted CAs and they know who the correct points of contact are.
  - jpalomaki 10y ago
    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.
jpalomaki 10y ago
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.
- mnordhoff 10y ago
  The standard way to do that is: example.com. CAA 0 issue ";" https://tools.ietf.org/html/rfc6844#section-5.2 https://tools.ietf.org/html/rfc6844#section-5.2
educar 10y ago
Last I checked route 53 did not support caa records yet. Any idea when they might be a available?

70 points by Mojah 10y ago

okket 10y ago

See also this great gist on CAA adoption: https://gist.github.com/roycewilliams/1710ade469c05eb0b090d268470aa741 https://gist.github.com/roycewilliams/1710ade469c05eb0b090d2... There was a little discussion on this topic yesterday: https://news.ycombinator.com/item?id=14068901 https://news.ycombinator.com/item?id=14068901 (12 comments)

pilif 10y ago

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.

methou 10y ago

But CAA is fully dependent on DNS(Sec).

koolba 10y ago
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.

devoply 10y ago

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.

tallanvor 10y ago

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.

koolba 10y ago
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.
- michaelt 10y ago
  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 :)
  - koolba 10y ago
    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!
  - okket 10y ago
    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...

davidgerard 10y ago

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.

pfg 10y ago
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.
tialaramex 10y ago
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.

kelnage 10y ago

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

homero 10y ago

Cloudflare hasn't even mentioned adding that record type

jffry 10y ago
It's apparently "in the works" (https://twitter.com/eastdakota/status/820376781320519680 https://twitter.com/eastdakota/status/820376781320519680 and https://twitter.com/grittygrease/status/820378094901096450 https://twitter.com/grittygrease/status/820378094901096450)
jgrahamc 10y ago
We are doing it right now.
- deleted 10y ago
  [deleted]

discreditable 10y ago

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.

kelnage 10y ago
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).
tialaramex 10y ago
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.

klodolph 10y ago

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.

discreditable 10y ago
> 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.
- klodolph 10y ago
  You already have a relationship with the whitelisted CAs and they know who the correct points of contact are.
- jpalomaki 10y ago
  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.

jpalomaki 10y ago

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.

mnordhoff 10y ago
The standard way to do that is: example.com. CAA 0 issue ";" https://tools.ietf.org/html/rfc6844#section-5.2 https://tools.ietf.org/html/rfc6844#section-5.2

educar 10y ago

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