10 ms·

Comodo fails to check CAA records

186 points by hannob 9y ago

zero_one_one 9y ago
That's quite incredible... It'd be interesting to see how up to date the CRL is as well.
Mojah 9y ago
Curious to see how the CAB will handle this or if they're going to be "soft" as it's the first days of the CAA enforcement. Historically, they've been very accurate in enforcing their rules, which could mean a serious reprimand of Comodo. If anyone is interested in testing their own CAA records, we built an online CAA validator specifically for this; https://dnsspy.io/labs/caa-validator https://dnsspy.io/labs/caa-validator
- michaelt 9y ago
  Between their decision to release a rebranded "more secure" version of Chrome where their changes had introduced security holes, and their decision to try and trademark "Let's Encrypt", I can't imagine they have many friends in the CAB. On the other hand, they issue a lot of certs - if you've used Cloudflare's free SSL stuff, you've got a Comodo certificate - so they're unlikely to be shut down or anything that extreme.
  - gsnedders 9y ago
    > On the other hand, they issue a lot of certs - if you've used Cloudflare's free SSL stuff, you've got a Comodo certificate - so they're unlikely to be shut down or anything that extreme. They're still smaller than Symantec, for whom the nuclear option was considered (and ultimately decided against, in favour of a phased distrusting).
- iancarroll 9y ago
  To clarify, the CA/B Forum has no enforcement powers. This would only really be an issue if a root program takes issue with it or their auditor qualifies their audit.
tehlike 9y ago
maybe time to revoke Comodo's CA authority. Similar to what has happened before with Symantec (?).
- scaryclam 9y ago
  Revocation for being three days late in implementing a new standard would be a massive overreaction. It would harm thousands of businesses in the process and would be extremely petty. Symantecs misdeeds are far worse than this.
  - wbl 9y ago
    Revocation can be done only for new certs. It's time to throw a CA to the dogs once in a while pour encourage les autres.
    - daenney 9y ago
      Not at all. Revoke trust in the signing authority and all it's certificates turn invalid the second that change hits. Update your OS's trust store to not trust Comodo anymore and you'll see the effects immediately in IE/Edge on Windows or Safari and Chrome on macOS (Firefox still ships its own CA bundle). It's just that when trust has been revoked in CAs recently, it's been done in a more gradual fashion to not hurt customers too much and give them time to migrate. After all, it's not the customer's fault the CA went rogue. This usually starts with not accepting certificates past a certain date but still validating previously issued ones, until sometime 6 months to a year later they're completely distrusted.
      - wbl 9y ago
        Which is exactly what I said above could be done.
        daenney 9y ago
        That's not at all what you said. What I replied to is where you literally said: > Revocation can be done only for new certs. That's not true. The "newness" of a cert or a CA has absolutely nothing to do with how, if and when it can be revoked.
ameliaquining 9y ago
Worth noting that the rule they broke has only been in effect for three days (https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/ https://cabforum.org/2017/03/08/ballot-187-make-caa-checking...). This might cause the CAB to go a bit easier on them.
- koolba 9y ago
  They also voted "yes" to the proposal and had 6 months to implement it.
  - Panino 9y ago
    Exactly. For some contrast: I use tinydns, which doesn't natively support CAA records. But I wanted them so I read the CAA spec and wrote a little tool to add support for these records using the generic record format. And I'm not even a programmer! (I can write a little code, nothing serious, and nobody would hire me for it.) And yet with all of Comodo's resources, they couldn't get this done? I can't take them seriously.
    - geofft 9y ago
      I'd assume that Comodo wrote the code, tested the code, deployed the code, and forgot to flip the switch to actually enable it in production.
- zokier 9y ago
  According to the mail, they have claimed to check CAA much earlier, so it's not just CAB guidelines they have broken, but their own word, which can be seen as worse.
naraniano 9y ago
Is it expected from all CAs that they obey CAA records, or is it something just made up by the community to crush the big CAs? I see an RFC from just a few years ago, and I'm not sure how these things are standardised.
- owenmarshall 9y ago
  Standardization goes through the CA/B forum. There was a ballot voted to make CAA checking mandatory for CAs[1], and COMODO voted yes for it. Any CA that issues certificates publicly need to check CAA from the 8th of September onward. [1] https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/ https://cabforum.org/2017/03/08/ballot-187-make-caa-checking...
  - naraniano 9y ago
    Ah, so they are three days late. That doesn't sound too serious.
    - scaryclam 9y ago
      Three days is quite a long time to be late, so I'd hope someone over there is getting a reprimand, but yeah, it's also not a disaster. They're response and time to remedy this will be more telling I think.
      - mynameisvlad 9y ago
        Three days over a weekend, though. Context matters. Even if it's the most critical incident, you can't force employees to work outside of business hours.
        Karunamon 9y ago
        Except they claimed to support it a long time before this. It’s not that they were late, it’s that they lied.
NelsonMinar 9y ago
Wikipedia has a nice list of previous Comodo malfeasance: https://en.wikipedia.org/wiki/Comodo_Group#Controversies https://en.wikipedia.org/wiki/Comodo_Group#Controversies Highlights include allowing fraudulent certs to be issued for Google, Yahoo, and Mozilla; working with a malware company; and trademark shenanigans with Let's Encrypt.
- chipperyman573 9y ago
  >working with a malware company Why is this a bad thing? A cert says "Yes, person x REALLY IS person x, and I can prove it mathematically." It doesn't say "Person x is trustworthy enough for me to vouch for them."
  - NelsonMinar 9y ago
    Who do you imagine they verified was Person X? More on the malware cert issuance: https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-mike-burgess-respond-to-comodo-s-ceo-on-comodo-certificates-issued-to-malware-distributors/ https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-mike... For malware concerns there's also Comodo's relationship with PrivDog. I'm not clear on whether PrivDog is deliberate malware or just incompetent insecure software.
    - cortesoft 9y ago
      That is ridiculous, to expect a CA to google every cert request domain and check what they are doing? That is a ridiculous requirement - cert issuance is automatic. Do you think we should stop allowing Let's Encrypt to issue certs? You know they don't google each domain to see what they are doing.
      - pitaj 9y ago
        In my opinion, it would be worse if they denied certs to certain people.
    - geofft 9y ago
floatingatoll 9y ago
Comodo is communicating actively in the bug, in the email discussion, and proactively CC'd the original reporter on the bug that was filed about this without being asked to do so. The general rule in Operations work is tolerance. You don't fire someone for making a mistake, you fire them for lying about the mistake, for refusing to avoid mistake-prone behaviors, and other problem of that sort. Applying that same principle to CA operations, why on earth should Comodo be "fired" as a CA for this? They're actively working to solve it, they're responsive, and the agreements they operate under will compel a post-mortem into existence if only to meet the terms of their next CA audit. If, after investigation, they are found to be willfully violating policy, knowingly lying about CAA support, fail to produce an acceptable post-mortem, and/or fail their next CA audit, then of course they should be at risk of direct sanctions - not just a verbal reprimand. So if your initial response to this issue is "Comodo should be fired", remember that in Operations culture that specific response "X should be fired" is a harmful response to a zero-day report of an incident, and many Operations teams would fire anyone who called for a firing in response to a fresh incident, in order to protect others from that harmful posture.
- tptacek 9y ago
  I would bet money (maybe not a lot of money, but money) that the only outcome of this is that Comodo ends up within a month being the CA that most reliably checks CAA records. It would be shocking if Google penalized them for this. As you say, that's based in part on how they handle it.
  - floatingatoll 9y ago
    The thing I'm sad to see is that there's no third-party information stated on when Comodo's CAA verification started and stopped. When they first announced CAA support, who tested it? When did it stop working? So I'm hoping this will come out of the post-mortem and be shared with us all.
    - agwa 9y ago
      Comodo is required by Mozilla to publish a public incident report: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance https://wiki.mozilla.org/CA/Responding_To_A_Misissuance
tptacek 9y ago
If you're not already familiar with his work, you should know that Hanno Böck is a machine, and someone worth following. If there's some mistake you can make with the web PKI that is so stupid nobody would ever bother to check for it, rest assured that Hanno will eventually check.
- hdhzy 9y ago
  Couldn't agree more, this (among others) was brilliant: https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-w...
  - antihero 9y ago
    Oh that's amazing. Imagine if he'd got, say, Google or Facebook's key revoked and the havoc it would wreak.
- AndyMcConachie 9y ago
  Yes!
- prdonahue 9y ago
  Hanno also writes the Bulletproof TLS Newsletter (https://www.feistyduck.com/bulletproof-tls-newsletter/ https://www.feistyduck.com/bulletproof-tls-newsletter/) which is highly informative. Suggest everyone interested in webPKI subscribe there as well.
jf 9y ago
If this is the first time you've heard of CAA records, note that the "dig" command isn't yet aware of these records types, so you need to tell it to use "type257" as the record type: $ dig empty.basic.caatestsuite.com type257 More resources here: https://support.dnsimple.com/articles/caa-record/ https://support.dnsimple.com/articles/caa-record/ https://caatestsuite.com/ https://caatestsuite.com/
- hannob 9y ago
  The dig command is totally aware of it if you have updated bind within the past couple of years.
- mike-cardwell 9y ago
  dig on Debian stable supports CAA just fine.
twothamendment 9y ago
This inspired me to add a CAA record for my domain - but https://www.namecheap.com https://www.namecheap.com doesn't support that record type. Has anyone had better luck other places?
- agwa 9y ago
  You may find my CAA website helpful: https://sslmate.com/caa/support https://sslmate.com/caa/support
  - twothamendment 9y ago
    I used your site - it was quick and easy. It soon went downhill from there. I don't run my own DNS or I'd be done pasting the line into my config. Instead I ran into a UI that doesn't support CAA as a type.
    - agwa 9y ago
      Unfortunately, if you want to use CAA your provider must support it. I recommend you use one of the DNS providers on the page I linked - there are quite a few to choose from.
- deleted 9y ago
  [deleted]
- daenney 9y ago
  Have you tried their support flow? They've usually been very responsive in my experience, it might just be around the corner.
PappaPatat 9y ago
CAA is fresh like IPv10. Done some tracking the last couple of months on the alexa top 1 million domains. In April 400(!) had CAA records. In August 800. 10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9) where it should be either 0 or 1. iodef set to totally unusable web addressed, you name it. As a matter of fact there are MANY large DNS service providers that do not even bother providing CAA options. If you want to name and shame, there is ample opportunity for the years to come. Getting it up and running is harder but more rewarding in the end.
- aaronmdjones 9y ago
  > 10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9) where it should be either 0 or 1. Are you certain? https://datatracker.ietf.org/doc/rfc6844/?include_text=1 https://datatracker.ietf.org/doc/rfc6844/?include_text=1 > The data fields are defined as follows: > > Flags: One octet containing the following fields: > > Bit 0, Issuer Critical Flag: If the value is set to '1', the > critical flag is asserted and the property MUST be understood > if the CAA record is to be correctly processed by a certificate > issuer. > > A Certification Authority MUST NOT issue certificates for any > Domain that contains a CAA critical property for an unknown or > unsupported property tag that for which the issuer critical > flag is set. > > Note that according to the conventions set out in [RFC1035], bit 0 > is the Most Significant Bit and bit 7 is the Least Significant > Bit. Thus, the Flags value 1 means that bit 7 is set while a value > of 128 means that bit 0 is set according to this convention. EDIT: Fixed formatting? I hope.

186 points by hannob 9y ago

That's quite incredible... It'd be interesting to see how up to date the CRL is as well.

Curious to see how the CAB will handle this or if they're going to be "soft" as it's the first days of the CAA enforcement. Historically, they've been very accurate in enforcing their rules, which could mean a serious reprimand of Comodo. If anyone is interested in testing their own CAA records, we built an online CAA validator specifically for this; https://dnsspy.io/labs/caa-validator https://dnsspy.io/labs/caa-validator

michaelt 9y ago
Between their decision to release a rebranded "more secure" version of Chrome where their changes had introduced security holes, and their decision to try and trademark "Let's Encrypt", I can't imagine they have many friends in the CAB. On the other hand, they issue a lot of certs - if you've used Cloudflare's free SSL stuff, you've got a Comodo certificate - so they're unlikely to be shut down or anything that extreme.
- gsnedders 9y ago
  > On the other hand, they issue a lot of certs - if you've used Cloudflare's free SSL stuff, you've got a Comodo certificate - so they're unlikely to be shut down or anything that extreme. They're still smaller than Symantec, for whom the nuclear option was considered (and ultimately decided against, in favour of a phased distrusting).
iancarroll 9y ago
To clarify, the CA/B Forum has no enforcement powers. This would only really be an issue if a root program takes issue with it or their auditor qualifies their audit.

tehlike 9y ago

maybe time to revoke Comodo's CA authority. Similar to what has happened before with Symantec (?).

scaryclam 9y ago
Revocation for being three days late in implementing a new standard would be a massive overreaction. It would harm thousands of businesses in the process and would be extremely petty. Symantecs misdeeds are far worse than this.
- wbl 9y ago
  Revocation can be done only for new certs. It's time to throw a CA to the dogs once in a while pour encourage les autres.
  - daenney 9y ago
    Not at all. Revoke trust in the signing authority and all it's certificates turn invalid the second that change hits. Update your OS's trust store to not trust Comodo anymore and you'll see the effects immediately in IE/Edge on Windows or Safari and Chrome on macOS (Firefox still ships its own CA bundle). It's just that when trust has been revoked in CAs recently, it's been done in a more gradual fashion to not hurt customers too much and give them time to migrate. After all, it's not the customer's fault the CA went rogue. This usually starts with not accepting certificates past a certain date but still validating previously issued ones, until sometime 6 months to a year later they're completely distrusted.
    - wbl 9y ago
      Which is exactly what I said above could be done.
      - daenney 9y ago
        That's not at all what you said. What I replied to is where you literally said: > Revocation can be done only for new certs. That's not true. The "newness" of a cert or a CA has absolutely nothing to do with how, if and when it can be revoked.

ameliaquining 9y ago

Worth noting that the rule they broke has only been in effect for three days (https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/ https://cabforum.org/2017/03/08/ballot-187-make-caa-checking...). This might cause the CAB to go a bit easier on them.

koolba 9y ago
They also voted "yes" to the proposal and had 6 months to implement it.
- Panino 9y ago
  Exactly. For some contrast: I use tinydns, which doesn't natively support CAA records. But I wanted them so I read the CAA spec and wrote a little tool to add support for these records using the generic record format. And I'm not even a programmer! (I can write a little code, nothing serious, and nobody would hire me for it.) And yet with all of Comodo's resources, they couldn't get this done? I can't take them seriously.
  - geofft 9y ago
    I'd assume that Comodo wrote the code, tested the code, deployed the code, and forgot to flip the switch to actually enable it in production.
zokier 9y ago
According to the mail, they have claimed to check CAA much earlier, so it's not just CAB guidelines they have broken, but their own word, which can be seen as worse.

naraniano 9y ago

Is it expected from all CAs that they obey CAA records, or is it something just made up by the community to crush the big CAs? I see an RFC from just a few years ago, and I'm not sure how these things are standardised.

owenmarshall 9y ago
Standardization goes through the CA/B forum. There was a ballot voted to make CAA checking mandatory for CAs[1], and COMODO voted yes for it. Any CA that issues certificates publicly need to check CAA from the 8th of September onward. [1] https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/ https://cabforum.org/2017/03/08/ballot-187-make-caa-checking...
- naraniano 9y ago
  Ah, so they are three days late. That doesn't sound too serious.
  - scaryclam 9y ago
    Three days is quite a long time to be late, so I'd hope someone over there is getting a reprimand, but yeah, it's also not a disaster. They're response and time to remedy this will be more telling I think.
    - mynameisvlad 9y ago
      Three days over a weekend, though. Context matters. Even if it's the most critical incident, you can't force employees to work outside of business hours.
      - Karunamon 9y ago
        Except they claimed to support it a long time before this. It’s not that they were late, it’s that they lied.

NelsonMinar 9y ago

Wikipedia has a nice list of previous Comodo malfeasance: https://en.wikipedia.org/wiki/Comodo_Group#Controversies https://en.wikipedia.org/wiki/Comodo_Group#Controversies Highlights include allowing fraudulent certs to be issued for Google, Yahoo, and Mozilla; working with a malware company; and trademark shenanigans with Let's Encrypt.

chipperyman573 9y ago
>working with a malware company Why is this a bad thing? A cert says "Yes, person x REALLY IS person x, and I can prove it mathematically." It doesn't say "Person x is trustworthy enough for me to vouch for them."
- NelsonMinar 9y ago
  Who do you imagine they verified was Person X? More on the malware cert issuance: https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-mike-burgess-respond-to-comodo-s-ceo-on-comodo-certificates-issued-to-malware-distributors/ https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-mike... For malware concerns there's also Comodo's relationship with PrivDog. I'm not clear on whether PrivDog is deliberate malware or just incompetent insecure software.
  - cortesoft 9y ago
    That is ridiculous, to expect a CA to google every cert request domain and check what they are doing? That is a ridiculous requirement - cert issuance is automatic. Do you think we should stop allowing Let's Encrypt to issue certs? You know they don't google each domain to see what they are doing.
    - pitaj 9y ago
      In my opinion, it would be worse if they denied certs to certain people.
  - geofft 9y ago

floatingatoll 9y ago

Comodo is communicating actively in the bug, in the email discussion, and proactively CC'd the original reporter on the bug that was filed about this without being asked to do so. The general rule in Operations work is tolerance. You don't fire someone for making a mistake, you fire them for lying about the mistake, for refusing to avoid mistake-prone behaviors, and other problem of that sort. Applying that same principle to CA operations, why on earth should Comodo be "fired" as a CA for this? They're actively working to solve it, they're responsive, and the agreements they operate under will compel a post-mortem into existence if only to meet the terms of their next CA audit. If, after investigation, they are found to be willfully violating policy, knowingly lying about CAA support, fail to produce an acceptable post-mortem, and/or fail their next CA audit, then of course they should be at risk of direct sanctions - not just a verbal reprimand. So if your initial response to this issue is "Comodo should be fired", remember that in Operations culture that specific response "X should be fired" is a harmful response to a zero-day report of an incident, and many Operations teams would fire anyone who called for a firing in response to a fresh incident, in order to protect others from that harmful posture.

tptacek 9y ago
I would bet money (maybe not a lot of money, but money) that the only outcome of this is that Comodo ends up within a month being the CA that most reliably checks CAA records. It would be shocking if Google penalized them for this. As you say, that's based in part on how they handle it.
- floatingatoll 9y ago
  The thing I'm sad to see is that there's no third-party information stated on when Comodo's CAA verification started and stopped. When they first announced CAA support, who tested it? When did it stop working? So I'm hoping this will come out of the post-mortem and be shared with us all.
  - agwa 9y ago
    Comodo is required by Mozilla to publish a public incident report: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance https://wiki.mozilla.org/CA/Responding_To_A_Misissuance

tptacek 9y ago

If you're not already familiar with his work, you should know that Hanno Böck is a machine, and someone worth following. If there's some mistake you can make with the web PKI that is so stupid nobody would ever bother to check for it, rest assured that Hanno will eventually check.

hdhzy 9y ago
Couldn't agree more, this (among others) was brilliant: https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-w...
- antihero 9y ago
  Oh that's amazing. Imagine if he'd got, say, Google or Facebook's key revoked and the havoc it would wreak.
AndyMcConachie 9y ago
Yes!
prdonahue 9y ago
Hanno also writes the Bulletproof TLS Newsletter (https://www.feistyduck.com/bulletproof-tls-newsletter/ https://www.feistyduck.com/bulletproof-tls-newsletter/) which is highly informative. Suggest everyone interested in webPKI subscribe there as well.

jf 9y ago

If this is the first time you've heard of CAA records, note that the "dig" command isn't yet aware of these records types, so you need to tell it to use "type257" as the record type: $ dig empty.basic.caatestsuite.com type257 More resources here: https://support.dnsimple.com/articles/caa-record/ https://support.dnsimple.com/articles/caa-record/ https://caatestsuite.com/ https://caatestsuite.com/

hannob 9y ago
The dig command is totally aware of it if you have updated bind within the past couple of years.
mike-cardwell 9y ago
dig on Debian stable supports CAA just fine.

twothamendment 9y ago

This inspired me to add a CAA record for my domain - but https://www.namecheap.com https://www.namecheap.com doesn't support that record type. Has anyone had better luck other places?

agwa 9y ago
You may find my CAA website helpful: https://sslmate.com/caa/support https://sslmate.com/caa/support
- twothamendment 9y ago
  I used your site - it was quick and easy. It soon went downhill from there. I don't run my own DNS or I'd be done pasting the line into my config. Instead I ran into a UI that doesn't support CAA as a type.
  - agwa 9y ago
    Unfortunately, if you want to use CAA your provider must support it. I recommend you use one of the DNS providers on the page I linked - there are quite a few to choose from.
deleted 9y ago
[deleted]
daenney 9y ago
Have you tried their support flow? They've usually been very responsive in my experience, it might just be around the corner.

PappaPatat 9y ago

CAA is fresh like IPv10. Done some tracking the last couple of months on the alexa top 1 million domains. In April 400(!) had CAA records. In August 800. 10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9) where it should be either 0 or 1. iodef set to totally unusable web addressed, you name it. As a matter of fact there are MANY large DNS service providers that do not even bother providing CAA options. If you want to name and shame, there is ample opportunity for the years to come. Getting it up and running is harder but more rewarding in the end.

aaronmdjones 9y ago
> 10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9) where it should be either 0 or 1. Are you certain? https://datatracker.ietf.org/doc/rfc6844/?include_text=1 https://datatracker.ietf.org/doc/rfc6844/?include_text=1 > The data fields are defined as follows: > > Flags: One octet containing the following fields: > > Bit 0, Issuer Critical Flag: If the value is set to '1', the > critical flag is asserted and the property MUST be understood > if the CAA record is to be correctly processed by a certificate > issuer. > > A Certification Authority MUST NOT issue certificates for any > Domain that contains a CAA critical property for an unknown or > unsupported property tag that for which the issuer critical > flag is set. > > Note that according to the conventions set out in [RFC1035], bit 0 > is the Most Significant Bit and bit 7 is the Least Significant > Bit. Thus, the Flags value 1 means that bit 7 is set while a value > of 128 means that bit 0 is set according to this convention. EDIT: Fixed formatting? I hope.