Hi everyone, we are currently conducting a measurement study about DNS staleness issues with a focus on IP address churning. We encountered the issue that Let's Encrypt (and ACME in general) can be (ab)used to request and receive a valid certificate for a domain, as long as the attacker obtains access to the IP address to which the DNS record points. This can happen due to stale DNS records (e.g., pointing to cloud providers), or through MitM attacks (e.g., as recently observed when an (accidental) BGP hijack re-routed all major payment processors via Moscow). The issued certificates are independent of the actual IP address used for the fraudulent certificate request, and can later be used for malicious purposes (local interception etc.).
Although it is a valid certificate request, we think that the ACMEv2 standard should mention practical ways to prevent these cases. This is especially the case, as the malicious certificate issuances may not necessarily attract attention through certificate transparency logs (as the domain points to the same IP address before/after). For example: Consider that Let's Encrypt is used by a service running a.example.com, where the A record of a.example.com points to 192.0.2.1 and 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS record, and 198.51.100.1 being an address for a VM instance in a cloud provider's pool. If an attacker now finds a way to allocate 198.51.100.1, she might also use Let's Encrypt to obtain a valid certificate. The certificate request by the attacker is indistinguishable from the outside and from interpreting the certificate transparency logs from what the legitimate operator would do to fix the service behind 198.51.100.1, which previously went stale. Since ACMEv2 is currently in draft, we think now is a good idea to bring up our proposal in the hope to incorporate parts of it into the draft. It relates closely to Yaron's and Jacob's earlier discussion on HTTPS authorization (acme-acme) and -to some degree- also to CAA (acme-caa). While stale DNS records are technically a DNS issue, we think that adding additional language to "11. Operational Considerations" is in the interest of the standard given the impact that it can have in the real world. We also propose, focusing on high-risk targets, a stricter issuance policy: If a valid certificate (e.g., issued by the same operator or a set of operators, checked via CT logs) exists for the requested domain, then the current challenge should be signed by the key. If the last certificate has expired, a grace period set by operators could apply (e.g., 1 month or 3 months). If the expiration date has passed a long time ago, or if no grace period is used by the operator, then a second channel should be used to verify the request (e.g., DNS CRP). This stricter issuance policy has the following benefits: * No burden in the normal and regular case * No (significant) burden if a domain changes ownership legitimately * Only minor and a one-time burden if a certificate has expired recently (depending on a grace period being used) At the same time, it prevents issuing certificates for domains that have stale DNS records (due to caching or not updated yet). Furthermore, it is a solution independent of CAA records, which is not a solution for all problems arising from stale DNS records (e.g., if a DNS record is stale, it points (A RR) to a cloud IP that an attacker gained control over, a CA is designated as allowed to issue certificates via a CAA RR, and the designated account at the CA is using an email address pointing to the same domain; in this case, the attacker can request a certificate valid for some months, giving ample time for an attack). While one could argue that an attacker could use a different domain-validating CA all together, HTTP Public Key Pinning could prevent her attacks in practice. In respect to high-risk targets, we are seeing significant staleness issues for domains pointing to IP addresses at various cloud providers in our study. Additionally, from our results, requesting the respective IP addresses quickly and automatically is practical for an attacker. Therefore, we would recommend to classify domains pointing to cloud providers as high-risk targets; practically, this should be a decision made by the operator and the standard should only inform the operator about the issue and possible solution. Please let us know what you think about the proposal. We would also be happy to share a version of our paper once we have finalized it for submission in the upcoming weeks. Best, Kevin On Wed, Jun 21, 2017 at 12:00 PM, <internet-dra...@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-07.txt > Pages : 74 > Date : 2017-06-21 > > Abstract: > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. Thus, certificate authorities in the Web PKI are > trusted to verify that an applicant for a certificate legitimately > represents the domain name(s) in the certificate. Today, this > verification is done through a collection of ad hoc mechanisms. This > document describes a protocol that a certification authority (CA) and > an applicant can use to automate the process of verification and > certificate issuance. The protocol also provides facilities for > other certificate management functions, such as certificate > revocation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
