Providing automation of domain ownership verification based on DNS records in ACME protocol

From a translator : This is a translation of an article from EFF
A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation .
Author of the original article: Joona Hoikkala.
Original publication date: February 23, 2018


Earlier this month, Let's Encrypt (the free, automated, open certification authority that EFF helped launch two years ago) crossed 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, which many system administrators have requested.

What is a wildcard certificate?


In order to verify the HTTPS certificate, the user's browser checks whether the website’s domain name is actually indicated 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 states: "I am valid for all subdomains in this domain," rather than explicitly listing them all. (This is indicated in the certificate using the 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 get the certificate for all of 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 challenge based on DNS , a domain name system that translates domain names such as www.eff.orgin IP addresses such as 69.50.232.54. From the point of view of a certification authority such as Let's Encrypt, there is no better way to prove that you manage a domain than by changing its DNS records, because 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, in order to automate it, the software requesting the certificate will also need to be able to modify the DNS records for this domain. In order to implement this feature, the software should also have access to the credentials for the DNS service (for example, login and password or cryptographic token), and these credentials should be stored where the certificate is automatically obtained.

In many cases, this means that if the machine processing the receiving process is compromised, the same thing happens with the DNS credentials, this is the real danger. In the rest of this post, we will dive deeply into the components involved in this process, and in which options make it safer.

How does domain ownership verification work?


At a high level, domain ownership verification works like all other automatic checks that are part of the ACME protocol — a protocol that a certification authority (CA), such as Let's Encrypt, and client software, such as Certbot, can exchange information about what certificate the server is requesting, and how the server should confirm ownership of the corresponding domain name.

During domain ownership verification, 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, the CA asks the client for proof of ownership of the domain by adding a specific TXT record to its DNS zone. In more detail: CA sends a unique random token to the ACME client, and those who have control over the domain must put this token as a TXT record in their DNS zone, in a predefined subdomain with the name "_acme-challenge" of that domain, control over which the user is trying to prove.

For example, if you are trying to verify the domain for * .eff.org, the verification subdomain would be "_acme-challenge.eff.org". When the token value is added to the DNS zone, the client tells the CA to continue the ownership check, after which the CA will perform a DNS query on the authoritative servers for the domain. If authoritative DNS servers respond with a DNS record containing the correct ownership verification token, ownership of the domain will be proved and the process of issuing the certificate can continue.

DNS service controls digital identity


The threats associated with the DNS zone makes it so dangerous that the DNS is what users' browsers rely on to know which IP address they should contact when trying to reach your domain. This applies to all services using a resolvable name under your domain, from email to web services.

When the DNS is compromised, an attacker can easily intercept all connections directed to your email or other secure service, stop encrypting TLS (since they can now verify the ownership of the domain and obtain 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, it would be very difficult to detect.

Separate and limited privileges


Strictly speaking, in order for the ACME client to make updates automatically, this client must have access only to credentials that can update 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 outside of major DNS zone updates or 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. CNAME records essentially act as links to another DNS record. Let's Encrypt will follow the CNAME record chain and enable the ownership verification 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 underlying problem, with varying levels of difficulty and security implications in the event of a compromise.

In the following sections, this post introduces some of these methods in an attempt to explain the possible consequences of the credentials being compromised. With one exception, they all use CNAME records.

Allow updates for TXT records only


The first way is to create a credential set with privileges that allow you to update TXT records.

In case of compromise, this method limits the consequences for the attacker to the ability to issue certificates for all domains in the DNS zone (since they can use DNS credentials to obtain their own certificates), as well as interrupt mail delivery. The impact on mail delivery comes from mail-specific TXT records, namely SPF , DKIM, and its extensions ADSP and DMARC . Their compromise will also facilitate the delivery of phishing emails posing as senders from a compromised domain.

Use "throwaway" confirmation domain


The second way is to manually create CNAME records for the _acme-challenge subdomain and point them to the verification domain, which 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 an external domain for verification. The domain used to verify ownership must be in the external DNS zone or in the subband DNS zone, which has its own set of credentials for management. (The subdelegate's DNS zone is defined using NS records and effectively delegates full control over part of the zone to an external source.)

The compromise effect for this method is quite limited. Since the actual stored credentials are for the external DNS zone, the attacker who received the credentials will only be able to issue certificates for all domains that point to records in this zone. However, figuring out which domains actually point there is trivial: an attacker just needs to read the certificate transparency logs and check if the domains in these certificates have a magic subdomain pointing to the vulnerable DNS zone.

Limited access to the DNS zone


If your software or DNS provider allows you to create permissions tied to a subdomain (granular privileges), this can help you mitigate the whole problem.

Unfortunately, at the time of publication, the only provider that provides these privileges was found - this is Microsoft Azure DNS . Dyn supposedly also has granular privileges, but we could not find a lower privilege level in their service besides “Updating Records”, which still leave the zone completely vulnerable.

Route53 and possibly others allow their users to create a subdelegate zone, new user credentials, indicate NS records in a new zone, and specify _acme-challenge verification subdomains for them using CNAME records. It takes a lot of work in order to correctly make 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 the ownership check.

Use ACME-DNS


Disclaimer: The software described below is written by the author (original article - approx. Translator), and it is used as an example of the functions needed to efficiently manage the credentials needed to automate the verification of domain ownership through DNS in a secure manner.

The last 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 opening a 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 updating TXT records of automatically generated random subdomains. There are no methods for requesting lost credentials, updating or adding other entries. It provides two endpoints:

  • / register - this endpoint creates a new subdomain for use, followed by a username and password. As an optional parameter, the register endpoint 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 point it to NS records to create a delegation node. After that, you simply create a new set of credentials through the endpoint / register and point the CNAME record from the sub-domain of the confirmation confirmation "_acme-challenge" 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 potential compromise on an attacker to the ability to issue certificates for these domains.

For more information about ACME-DNS, see:
github.com/joohoi/acme-dns

Conclusion


To resolve issues with domain ownership verification through ACME DNS, suggestions such as assisted-DNS in the ACME IETF working group were discussed , but currently these problems are still not resolved. Since the only way to limit the impact of compromise is to restrict the access rights of DNS zone accounts to change certain TXT records, the current possibilities for reliable implementation of domain ownership verification automation are insignificant.

The only sustainable option would be to force the DNS software and service providers to either implement methods to create smaller zone credentials, or to provide a completely new type of credential for this specific use case.

Also popular now: