Ensuring automation of domain ownership verification based on ACME DNS records [translation]
From the translator : This is a translation of an article from EFF
A Technical Deep Dive: Securing the ACME DNS Challenge Validation .
The author of the original article: Joona Hoikkala.
Date of an original publication: February 23, 2018
Earlier this month, Let's Encrypt (a free, automated, open certificate authority that EFF helped launch two years ago) broke an important milestone: issuing more than 50 million active certificates . And this number will continue to grow, because in a few weeks Let's Encrypt will also start issuing wildcard certificates that many system administrators have requested.
To verify the HTTPS certificate, the user's browser checks whether the domain name of the web site is specified in the certificate. For example, a certificate from www.eff.org should actually include www.eff.org as a valid domain for this certificate. Certificates can also contain multiple domains (for example, www.eff.org , ssd.eff.org, sec.eff.org, etc.) if the owner simply wants to use one certificate for all of their domains.
A wildcard certificate is a certificate that says: “I am valid for all subdomains in this domain,” rather than listing them explicitly. (In the certificate, this is indicated by a wildcard character indicated by an asterisk. Therefore, if you now check the certificate for eff.org, it will say that it is valid for * .eff.org.) Thus, the system administrator can obtain a certificate for all his domain and use it in new subdomains, which he did not even think about when he received the certificate.
')
To issue wildcard certificates, Let's Encrypt will require users to confirm their domain control using a DNS- based challenge (challenge) check, which translates domain names, such as www.eff.org , into IP addresses, such as 69.50.232.54. From a certification authority point of view, such as Let's Encrypt, there is no better way to prove that you are managing a domain than by changing its DNS records, since domain management is one of the foundations of DNS.
However, one of the key ideas of Let's Encrypt is that obtaining a certificate should be an automatic process. But to automate it, software requesting a certificate will also need to be able to change the DNS records for this domain. In order to implement this feature, the software must also have access to the credentials for the DNS service (for example, a login and password or a cryptographic token), and these credentials should be stored where automated certification is obtained.
In many cases, this means that if the machine processing process is compromised, the same happens with the DNS credentials, this is the real danger. In the remainder of this post, we will go deep into the components involved in this process, and in what options do it make it safer.
At a high level, a domain ownership check works like all other automatic checks that are part of the ACME protocol, a protocol that a certificate authority (CA) can use, such as Let's Encrypt, and client software, such as Certbot, to exchange information about which certificate the server is requesting, and how the server must confirm ownership of the corresponding domain name.
During a domain ownership check, the user requests a certificate from the CA using ACME client software, such as Certbot, which supports this type of verification. When a client requests a certificate, CA requests the client to verify domain ownership by adding a specific TXT record to its DNS zone. In more detail: The CA sends a unique random token to the ACME client, and the person who has control of the domain must place this token as a TXT record in his DNS zone, in a predefined subdomain named "_acme-challenge" of the domain whose control is trying to prove the user.
For example, if you are trying to check the domain for * .eff.org, the verification subdomain will be "_acme-challenge.eff.org". When the value of the token is added to the DNS zone, the client informs the CA to continue to verify ownership, after which the CA will perform a DNS query to the authoritative servers for the domain. If the authoritative DNS servers respond with a DNS record containing the correct ownership verification token, the domain ownership will be proved and the certificate issuance process can continue.
The threats posed by the DNS zone make it so dangerous that DNS is something that users' browsers rely on to know which IP address they should contact when trying to reach your domain. This applies to all services that use a resolvable name under your domain, from email to web services.
When a DNS is compromised, an attacker can easily intercept all connections sent to your email or other protected service, terminate TLS encryption (since they can now verify domain ownership and get their valid certificates for them), decrypt the data and read them, and then re-encrypt the data and transfer it to your server. For most people, this would be very difficult to detect.
Strictly speaking, in order for the ACME client to do updates in automatic mode, this client should have access only to the credentials that can update the TXT records for the "_acme-challenge" subdomains. Unfortunately, most DNS software products and DNS service providers do not offer detailed access controls that limit these privileges, or simply do not provide an API to automate this beyond basic updates or DNS zone transactions. This leaves possible automation methods unsuitable or unsafe.
There is a simple way that can help maneuver past such restrictions: use a CNAME record . CNAMEs essentially act as links to another DNS record. Let's Encrypt follow the chain of CNAME records and allow the ownership check token for the last record in the chain.
Even using CNAME records, the main problem is that the ACME client will still need access to credentials that will allow it to change some DNS record. There are various ways to mitigate this basic problem with different levels of complexity and security implications in the event of a compromise.
In the following sections, this post presents some of these methods, trying to explain the possible consequences of having credentials compromised. With one exception, they all use CNAME records.
The first way is to create a set of credentials with privileges that allow you to update TXT records.
If compromised, this method limits the attacker's ability to issue certificates for all the domains in the DNS zone (since they can use the DNS credentials to get their own certificates), as well as interrupting mail delivery. The impact on mail delivery comes from mail-specific TXT records, namely SPF , DKIM and its ADSP and DMARC extensions. Their compromise will also facilitate the delivery of phishing emails that pretend to be the sender from the compromised domain.
The second way is to manually create CNAME records for the "_acme-challenge" subdomain and point them to the verification domain that will be in the zone controlled by another set of credentials.
For example, if you want to get a certificate to cover "yourdomain.tld" and " www.yourdomain.tld ", you will have to create two CNAME records - "_ acme-challenge.yourdomain.tld" and "_acme-challenge.www.yourdomain .tld "- and also point them to the external domain for verification. The domain used to verify ownership must be in the outer DNS zone or in the sub-band DNS zone, which has its own set of management credentials. (The DNS zone of the subdelegate is determined using NS records and in fact delegates full control over part of the zone to an external source.)
The effect of compromise for this method is rather limited. Since the actual stored credentials are intended for the external DNS zone, an attacker who received the credentials will only be able to issue certificates for all domains pointing to records in this zone. However, figuring out which domains actually point there is trivial: an attacker simply needs to read the transparency logs of the certificates and check whether the domains in these certificates have a magic subdomain pointing to the vulnerable DNS zone.
If your software or DNS provider allows you to create permissions associated with a subdomain (granular privileges), this can help you alleviate the entire problem.
Unfortunately, at the time of publication, the only provider that found these privileges was found - Microsoft Azure DNS . Dyn presumably also has granular privileges, but we could not find a lower level of privileges in their service besides “Update Records”, which still leave the zone completely vulnerable.
Route53 and possibly others allow their users to create a subdelegate zone, new user credentials, specify NS records in the new zone and specify _acme-challenge subdomains for checking them using CNAME records. It takes a lot of work to correctly do the distribution of privileges using this method, since you need to go through all these steps for each domain for which you need to use a proprietary check.
Disclaimer: the software described below is written by the author (the original article - approx. Translator), and it is used as an example of the functions needed to effectively manage the credentials needed to automate the verification of domain ownership via DNS in a secure way.
The latter method is a piece of software called ACME-DNS written to deal specifically with the problem under discussion, and it can completely eliminate it. The only drawback is that this method adds another component to your infrastructure that needs to be supported, and also requires you to open the DNS port (53) for public access to the Internet.
ACME-DNS acts as a simple DNS server with a limited HTTP API. The API itself allows only to update TXT records of automatically generated random subdomains. It has no methods for querying lost credentials, updating or adding other records. It provides two end points:
To use ACME-DNS, you first need to create A / AAAA records for it, and then specify NS records for it to create a delegation node. After that, you simply create a new set of credentials through the / register end point and specify the CNAME record from the confirmation subfield of the "_acme-challenge" verification in the source zone to the newly created subdomain.
The only credentials stored locally will be for ACME-DNS, and they are only good for updating accurate TXT records for verification subdomains for domains in the field. This effectively limits the impact of a possible compromise for the attacker to the ability to issue certificates for these domains.
For more information about ACME-DNS, see the page:
github.com/joohoi/acme-dns
To eliminate problems with checking domain ownership through ACME DNS, suggestions such as assisted-DNS in the ACME IETF working group were discussed, but at present these problems are still without resolution. Since the only way to limit the impact of a compromise is to limit the access rights of the accounts of the DNS zones before changing certain TXT records, the current possibilities for reliable implementation of the automation of the domain ownership check are insignificant.
The only sustainable option would be to force the DNS software and service providers to either implement methods for creating smaller-scale zone credentials, or provide a completely new type of credential for this particular use case.
A Technical Deep Dive: Securing the ACME DNS Challenge Validation .
The author of the original article: Joona Hoikkala.
Date of an original publication: February 23, 2018
Earlier this month, Let's Encrypt (a free, automated, open certificate authority that EFF helped launch two years ago) broke an important milestone: issuing more than 50 million active certificates . And this number will continue to grow, because in a few weeks Let's Encrypt will also start issuing wildcard certificates that many system administrators have requested.
What is a wildcard certificate?
To verify the HTTPS certificate, the user's browser checks whether the domain name of the web site is specified in the certificate. For example, a certificate from www.eff.org should actually include www.eff.org as a valid domain for this certificate. Certificates can also contain multiple domains (for example, www.eff.org , ssd.eff.org, sec.eff.org, etc.) if the owner simply wants to use one certificate for all of their domains.
A wildcard certificate is a certificate that says: “I am valid for all subdomains in this domain,” rather than listing them explicitly. (In the certificate, this is indicated by a wildcard character indicated by an asterisk. Therefore, if you now check the certificate for eff.org, it will say that it is valid for * .eff.org.) Thus, the system administrator can obtain a certificate for all his domain and use it in new subdomains, which he did not even think about when he received the certificate.
')
To issue wildcard certificates, Let's Encrypt will require users to confirm their domain control using a DNS- based challenge (challenge) check, which translates domain names, such as www.eff.org , into IP addresses, such as 69.50.232.54. From a certification authority point of view, such as Let's Encrypt, there is no better way to prove that you are managing a domain than by changing its DNS records, since domain management is one of the foundations of DNS.
However, one of the key ideas of Let's Encrypt is that obtaining a certificate should be an automatic process. But to automate it, software requesting a certificate will also need to be able to change the DNS records for this domain. In order to implement this feature, the software must also have access to the credentials for the DNS service (for example, a login and password or a cryptographic token), and these credentials should be stored where automated certification is obtained.
In many cases, this means that if the machine processing process is compromised, the same happens with the DNS credentials, this is the real danger. In the remainder of this post, we will go deep into the components involved in this process, and in what options do it make it safer.
How does domain ownership check work?
At a high level, a domain ownership check works like all other automatic checks that are part of the ACME protocol, a protocol that a certificate authority (CA) can use, such as Let's Encrypt, and client software, such as Certbot, to exchange information about which certificate the server is requesting, and how the server must confirm ownership of the corresponding domain name.
During a domain ownership check, the user requests a certificate from the CA using ACME client software, such as Certbot, which supports this type of verification. When a client requests a certificate, CA requests the client to verify domain ownership by adding a specific TXT record to its DNS zone. In more detail: The CA sends a unique random token to the ACME client, and the person who has control of the domain must place this token as a TXT record in his DNS zone, in a predefined subdomain named "_acme-challenge" of the domain whose control is trying to prove the user.
For example, if you are trying to check the domain for * .eff.org, the verification subdomain will be "_acme-challenge.eff.org". When the value of the token is added to the DNS zone, the client informs the CA to continue to verify ownership, after which the CA will perform a DNS query to the authoritative servers for the domain. If the authoritative DNS servers respond with a DNS record containing the correct ownership verification token, the domain ownership will be proved and the certificate issuance process can continue.
DNS service controls digital identity
The threats posed by the DNS zone make it so dangerous that DNS is something that users' browsers rely on to know which IP address they should contact when trying to reach your domain. This applies to all services that use a resolvable name under your domain, from email to web services.
When a DNS is compromised, an attacker can easily intercept all connections sent to your email or other protected service, terminate TLS encryption (since they can now verify domain ownership and get their valid certificates for them), decrypt the data and read them, and then re-encrypt the data and transfer it to your server. For most people, this would be very difficult to detect.
Separate and limited privileges
Strictly speaking, in order for the ACME client to do updates in automatic mode, this client should have access only to the credentials that can update the TXT records for the "_acme-challenge" subdomains. Unfortunately, most DNS software products and DNS service providers do not offer detailed access controls that limit these privileges, or simply do not provide an API to automate this beyond basic updates or DNS zone transactions. This leaves possible automation methods unsuitable or unsafe.
There is a simple way that can help maneuver past such restrictions: use a CNAME record . CNAMEs essentially act as links to another DNS record. Let's Encrypt follow the chain of CNAME records and allow the ownership check token for the last record in the chain.
Ways to mitigate the problem
Even using CNAME records, the main problem is that the ACME client will still need access to credentials that will allow it to change some DNS record. There are various ways to mitigate this basic problem with different levels of complexity and security implications in the event of a compromise.
In the following sections, this post presents some of these methods, trying to explain the possible consequences of having credentials compromised. With one exception, they all use CNAME records.
Allow updates for TXT records only.
The first way is to create a set of credentials with privileges that allow you to update TXT records.
If compromised, this method limits the attacker's ability to issue certificates for all the domains in the DNS zone (since they can use the DNS credentials to get their own certificates), as well as interrupting mail delivery. The impact on mail delivery comes from mail-specific TXT records, namely SPF , DKIM and its ADSP and DMARC extensions. Their compromise will also facilitate the delivery of phishing emails that pretend to be the sender from the compromised domain.
Use the "throwaway" verification domain
The second way is to manually create CNAME records for the "_acme-challenge" subdomain and point them to the verification domain that will be in the zone controlled by another set of credentials.
For example, if you want to get a certificate to cover "yourdomain.tld" and " www.yourdomain.tld ", you will have to create two CNAME records - "_ acme-challenge.yourdomain.tld" and "_acme-challenge.www.yourdomain .tld "- and also point them to the external domain for verification. The domain used to verify ownership must be in the outer DNS zone or in the sub-band DNS zone, which has its own set of management credentials. (The DNS zone of the subdelegate is determined using NS records and in fact delegates full control over part of the zone to an external source.)
The effect of compromise for this method is rather limited. Since the actual stored credentials are intended for the external DNS zone, an attacker who received the credentials will only be able to issue certificates for all domains pointing to records in this zone. However, figuring out which domains actually point there is trivial: an attacker simply needs to read the transparency logs of the certificates and check whether the domains in these certificates have a magic subdomain pointing to the vulnerable DNS zone.
Restricted access to the DNS zone
If your software or DNS provider allows you to create permissions associated with a subdomain (granular privileges), this can help you alleviate the entire problem.
Unfortunately, at the time of publication, the only provider that found these privileges was found - Microsoft Azure DNS . Dyn presumably also has granular privileges, but we could not find a lower level of privileges in their service besides “Update Records”, which still leave the zone completely vulnerable.
Route53 and possibly others allow their users to create a subdelegate zone, new user credentials, specify NS records in the new zone and specify _acme-challenge subdomains for checking them using CNAME records. It takes a lot of work to correctly do the distribution of privileges using this method, since you need to go through all these steps for each domain for which you need to use a proprietary check.
Use ACME-DNS
Disclaimer: the software described below is written by the author (the original article - approx. Translator), and it is used as an example of the functions needed to effectively manage the credentials needed to automate the verification of domain ownership via DNS in a secure way.
The latter method is a piece of software called ACME-DNS written to deal specifically with the problem under discussion, and it can completely eliminate it. The only drawback is that this method adds another component to your infrastructure that needs to be supported, and also requires you to open the DNS port (53) for public access to the Internet.
ACME-DNS acts as a simple DNS server with a limited HTTP API. The API itself allows only to update TXT records of automatically generated random subdomains. It has no methods for querying lost credentials, updating or adding other records. It provides two end points:
- / register - this endpoint creates a new subdomain to use, followed by a username and password. As an optional parameter, the endpoint of the register accepts a list of CIDR ranges for “white” updates.
- / update - this endpoint is used to update the current domain ownership check token on the server.
To use ACME-DNS, you first need to create A / AAAA records for it, and then specify NS records for it to create a delegation node. After that, you simply create a new set of credentials through the / register end point and specify the CNAME record from the confirmation subfield of the "_acme-challenge" verification in the source zone to the newly created subdomain.
The only credentials stored locally will be for ACME-DNS, and they are only good for updating accurate TXT records for verification subdomains for domains in the field. This effectively limits the impact of a possible compromise for the attacker to the ability to issue certificates for these domains.
For more information about ACME-DNS, see the page:
github.com/joohoi/acme-dns
Conclusion
To eliminate problems with checking domain ownership through ACME DNS, suggestions such as assisted-DNS in the ACME IETF working group were discussed, but at present these problems are still without resolution. Since the only way to limit the impact of a compromise is to limit the access rights of the accounts of the DNS zones before changing certain TXT records, the current possibilities for reliable implementation of the automation of the domain ownership check are insignificant.
The only sustainable option would be to force the DNS software and service providers to either implement methods for creating smaller-scale zone credentials, or provide a completely new type of credential for this particular use case.
Source: https://habr.com/ru/post/350202/
All Articles