On Thu, Jul 20, 2017 at 12:18:10AM -0700, Kevin Borgolte wrote: > 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).
The methods in base spec just fundamentially rely on security of DNS. The only way to remove dependence on routing would be: 1) Deploy DNSSEC and 2) Add acme-CAA record restricting validation to DNS. > 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. Stale IP addresses cause problems when renewing (however, that does not occur that often). Also, due to recent "fixes", IPv6 stale addresses can be missed (there are just so many folks with busted DNS configuraiton). And I think that would also cause large amounts of problems for users if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides the problem). > 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). There was PoP challenge in earlier versions of ACME spec for exactly that. However, it was removed, because it seemed to be more trouble than worth, and because it signed JSON messages with key intended for something else, which is cryptographically not kosher (and contexts are unusable in real world). In the "order flow" change, did put the CSR first so one can look up the requested key first. However, this would cause major problems if trying to change keys (and many (I am not among them) believe that rotating private keys often is important). This would also complicate "disaster recovery" where the previous keys are lost (usually due to admin mistake, and backups being AWOL like usual). You would not believe how often that happens (and I hear just a small subset). > 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) Err, what? These don't seem even remotely right to me. > 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). Caching should not be a big issue: LE limits the cache validity to pretty short values. How many times has LE issued certificate to wrong actor due to stale DNS data (I am aware of at least one DNS hijack incident, but protecting against those is considered too high bar for CAs, even DNSSEC would not have helped). > 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. Unfortunately, HPKP is pretty hard to deploy: CA HPKP has two major problems: - CAs rotating intermediate keys in unpredictable ways (upcoming LE ECDSA intermediate anyone?). - Chain-building problems, especially with Chrome. Sending the pinned intermediate in legal chain does not imply that HPKP will pass! EE HPKP does not fail due to CAs rotating keys or chain-building issues, however: - One needs to be serious about backups. And EE HPKP would take care of this problem by itself anyway. > 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. Unfortunately domains pointing at cloud provoders is pretty common, and classifying those as high-risk would cause major issues for legimate users. > 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. I think it is a bad bad idea. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
