DigiCert Revocation Incident (CNAME Domain Validation)
1–10 of 56 posts
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#2[deleted]
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#3https://bugzilla.mozilla.org/show_bug.cgi?id=1910322
for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give you control of yourusername.example.com and they don't want to make it possible for random users to register the random string and be able to manipulate it. If you don't allow users to generate anything that causes a hostname to appear with a leading underscore, they can't pass the domain validation.
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#4https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give…
Also, while a DNS name can have an underscore a host name, even in DNS, cannot have this character. So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.
So even if you are completely oblivious to this work, and don't care about security at all, your "Give everybody a hostname" code should already avoid underscore characters as desired because otherwise stuff breaks.
Several current systems use DNS names (but not hostnames) which feature underscores but it's pretty unlikely that you've got (for example) a service where users can pick their own TCP/IP service name and port and issued appropriate records for it in DNS. If you have done this weird thing you probably want to use the existing mechanism (in DNS of course, the CAA record) to tell most CAs that they should not issue for your names even if they think they've received permission. You can then cut a suitable deal with a for-profit CA to do whatever crazy extra checks you want (e.g. Meta's CA has to contact actual people in the appropriate security team at Meta, so that "mistakes" which give somebody a certificate for facebook.com never happen without some pretty drastic real world errors).
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#5> The underscore prefix ensures that the random value cannot collide with an actual domain name that uses the same random value. While the odds of that happening are practically negligible, the validation is still deemed as non-compliant if it does not include the underscore prefix.
That's not the rationale for mandating the underscore prefix. The actual reason is so services that allow users to create DNS records at subdomains (e.g. dynamic DNS services) can block users from registering subdomains starting with an underscore. It serves the same purpose that /.well-known does.
For example, if an attacker requests a certificate for dyndns.example and DigiCert gives them a record without an underscore prefix like da39a3ee5e6b4b0d3255bfef95601890afd80709.dyndns.example, they can register that subdomain with the dynamic DNS provider, publish the required record, and get the certificate for dyndns.example. It doesn't matter how much entropy DigiCert put in the record name.
I definitely commend DigiCert for pledging to revoke the certificates within 24 hours and not having a delayed revocation or trying to language lawyer their way to a 5 day revocation as other CAs have tried. Nevertheless, this post severely minimizes the security impact of their mistake, and provides an excellent example of why CAs should always be required to strictly adhere to the rules and not be permitted to excuse noncompliance based on their own security analysis.
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#6https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give…
Also, while a DNS name can have an underscore a host name, even in DNS, cannot have this character. So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid. So even if you are completely oblivious to this work, and don't care about security at all, your "Give everybody a hostnam…
So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.
Not long ago I actually did come across a site that had an underscore in its domain name, and it worked both for me and apparently Google, because it indexed and showed a (relevant) page from that site. I only remembered it was on a *.tripod.com subdomain, and can't find that exact site now since I don't remember what I was searching for (it was a highly obscure and technical topic), but there do appear to be others there with underscores, e.g.:
http://computer_collector.tripod.com/
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#7Earlier quoted context omitted.
Also, while a DNS name can have an underscore a host name, even in DNS, cannot have this character. So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid. So even if you are completely oblivious to this work, and don't care about security at all, your "Give everybody a hostnam…
So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid. Not long ago I actually did come across a site that had an underscore in its domain name, and it worked both for me and apparently Google, because it indexed and showed a (relevant) page from that site. I only remembered i…
[deleted]
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#8> The underscore prefix ensures that the random value cannot collide with an actual domain name that uses the same random value. While the odds of that happening are practically negligible, the validation is still deemed as non-compliant if it does not include the underscore prefix. That's not the rationale for mandating the underscore prefix. The actual reason is so services that allow users to create DNS records at…
> For example, if an attacker requests a certificate for dyndns.example
Shouldn't that get caught by the Public Suffix List?
I would hope DigiCert has checks in place to prevent someone domain-validating ownership of the entire of co.uk under any circumstances :)
(They should still revoke the mis-issued certificates though)
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#9I just want to call out both CrowdStrike and DigiCert for being one of "those" companies that insist on publishing critical support information behind a login with the clock ticking on a global outage of their own making.
There are no polite words that I can use to accurately convey the depth of my disappointment at this kind of inconsiderate behaviour during a crisis, so I won't say anything more.
Re: DigiCert Revocation Incident (CNAME Domain Validation)
#10I just want to call out both CrowdStrike and DigiCert for being one of "those" companies that insist on publishing critical support information behind a login with the clock ticking on a global outage of their own making. There are no polite words that I can use to accurately convey the depth of my disappointment at this kind of inconsiderate behaviour during a crisis, so I won't say anything more.
Are you referring to the list of affected certificates?