New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support demonstrating that the ACME client speaks for a DNS wildcarded hostname space #64

Closed
hsivonen opened this Issue Feb 10, 2015 · 17 comments

Comments

Projects
None yet
@hsivonen

hsivonen commented Feb 10, 2015

Copying and pasting from letsencrypt/boulder#21

According to a presentation by Seth Schoen and according to brief inspection of the CA source code, Let's Encrypt is planning on not issuing wildcard certificates. IIRC, the reason given by Schoen was the lack of a method of checking that the ACME client really speaks for the whole domain subspace. Furthermore, it was observed that being able to quickly meant non-wildcard certificates for a particular host names in an automated fashion without payment makes wildcard certificates less necessary.

This doesn't address the wildcard use case that Sandstorm (https://sandstorm.io/) has: Minting randomly-generated host names all the time in order to generate new unguessable origins. In order for newly-minted origins to work immediately, it doesn't make sense to wait even for fast automatic certificate issuance. Also, I would imagine that as long as the Baseline Requirements don't exempt short-lived certificates from revocation infrastructure requirements, Let's Encrypt might not be too keen to have servers generate certs for throw-away hostnames all the time.

To address this use case, I suggest that Let's Encrypt issues a wildcard certificate when the ACME client can demonstrate that it speaks for several hostnames that are randomly generated by the Registration Authority. For some reasonable value for "several", the RA should be able to convince itself that there exists a DNS wildcard that makes hostnames that would match the requested wildcard certificates point to the server running the ACME client.

This issue is to request an ACME protocol addition for the RA to be able to present the client the sort of challenge described in the above paragraph.

(CONTRIBUTING.md says I should email a mailing list, but the list name is a placeholder. Please let me know if I should email this somewhere.)

@lgarron

This comment has been minimized.

lgarron commented Feb 10, 2015

For some reasonable value for "several", the RA should be able to convince itself that there exists a DNS wildcard that makes hostnames that would match the requested wildcard certificates point to the server running the ACME client.

Maybe I'm missing something. All I can infer is that someone is able to ask for arbitrary subdomains from the owner.

Even github.io allows this (albeit restricted).

Could you explain the approach for preventing such an attack?

@jsha

This comment has been minimized.

Collaborator

jsha commented Feb 10, 2015

Any validation for *.github.io would definitely have to include a validation for github.io as well.

An additional layer of protection: The server could make requests to random subdomains without disclosing them to the client. So the client would have to have set up DNS wildcarding ahead of time to point at their server.

@schoen

This comment has been minimized.

schoen commented Feb 10, 2015

There are other domains that also allow relatively unprivileged users to request new subdomains -- mit.edu seems like a good example. (Although https://scripts.mit.edu/faq/14/ says that they are "manually approved", which I didn't know and which would make it harder to use that to attack this kind of verification process.) Maybe wordpress.com is another example?

@schoen

This comment has been minimized.

schoen commented Feb 10, 2015

@jsha: how about requiring a TXT record at the top level, e.g. github.io IN TXT acme-domain-control-validation-d78931fcf2660108eec0d6674ecb4e02401b5256a6b5ee82527766ef6d198c67?

@jsha

This comment has been minimized.

Collaborator

jsha commented Feb 10, 2015

I think a TXT record at top level may be what existing CAs require before providing a wildcard certificate, and is probably sufficient to prove what we want. The proposals I mention above might or might not be more secure, though it's hard to evaluate without a threat model.

How does adding a TXT record differ operationally for our already-spec'ed DNS challenge? It would be nice to be able to reuse where possible.

@martinthomson

This comment has been minimized.

Contributor

martinthomson commented Feb 11, 2015

(CONTRIBUTING.md says I should email a mailing list, but the list name is a placeholder. Please let me know if I should email this somewhere.)

That's probably my fault, acme@ietf.org is a good venue for discussion.

Rather than launch straight into a design, which seems perfectly tractable (as above) I'd suggest that someone decide how to prioritize this against the other work going on. In terms of specification, this seems a wholly appropriate extension document.

@diracdeltas

This comment has been minimized.

diracdeltas commented Mar 23, 2015

+1 for getting this into the ACME spec or as an extension doc, based on interest from Sandstorm and others. I imagine the performance impact for sites like Hackpad/Tumblr/Wordpress/etc. to request an ACME cert every time someone signs up or creates a new blog is prohibitively high.

@jsha: Existing CA's generally use the same domain verification procedure for wildcard certs as for regular DV certs, plus the checks in https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf, section 11.1.3. For myself and everyone I've heard of who went through this process, this was just an email to the WHOIS address or {admin,webmaster,etc.}@example.com.

AFAICT, presenting a DNS TXT record with the CA-provided challenge token for the top-level domain + checking the domain has in fact set up wildcard DNS + following the CAB's public suffix guideline is sufficient.

@titanous

This comment has been minimized.

Contributor

titanous commented Mar 23, 2015

+1 for explicit validation of the wildcard DNS using random domains. I'd prefer if the DNS TXT record was not required, as doing multiple DVSNI tests against random subdomains plus the primary domain should be sufficient.

My use case is a product where we have the user install hosting software on some servers and configure a DNS wildcard. We want to keep the DNS setup minimal, and then provide easy automated provisioning of TLS certificates including a wildcard certificate. Requiring a custom TXT record after our software does the ACME dance to get it would severely impact the installation experience for our users.

@diracdeltas

This comment has been minimized.

diracdeltas commented Mar 23, 2015

4snjlka

(by "both," I mean "either/or")

@titanous

This comment has been minimized.

Contributor

titanous commented Mar 23, 2015

👍 to either/or. DVSNI will be more complicated to configure than TXT records in some environments.

@kentonv

This comment has been minimized.

kentonv commented Mar 23, 2015

I said in an e-mail earlier that the TXT approach would be easiest for Sandstorm, but on second thought I think that's not correct. I think DVSNI is our preference as well. Responding from multiple random hosts within the wildcard sounds fine.

(Details: The DNS TXT approach would be easiest if only considering sandcats.io (our turnkey dynamic DNS service) where we (Sandstorm the company) are in control of DNS so can implement anything easily, but not true for users trying to set up under their own domain. Whatever we do to support the latter will work for the former as well, and it's probably best to use the same code, making SSL setup and sandcats.io setup completely independent.)

@diracdeltas

This comment has been minimized.

diracdeltas commented Mar 24, 2015

In that case, it sounds like we should definitely add wildcard DVSNI to the spec and have it as a first implementation goal. DNS TXT with a challenge string would also be straightforward; I learned that it's not uncommon for CAs to use this for verification, as @jsha mentioned. The CAB guidelines don't go into detail about how this should be done, but I talked to a CA who says that they check the DNS TXT record thusly:

  1. If the request is for *.example.com, the record must be on either example.com or www.example.com.
  2. If the request is for *.subdomain.example.com, the record must be on either subdomain.example.com, example.com, or www.example.com.

As far as I can see, there is no security difference in applying these rules to DNS TXT vs DVSNI challenges.

@pde mentioned in person just now that many CAs require human-in-the-loop verification for wildcard certs (given the security risks), so it makes sense for ACME to be more conservative than what the CAB requires and what existing CA's do for wildcard verification. I think the following additional restrictions make sense for ACME:

  1. Verification of *.example.com must happen at example.com
  2. Verification of *.subdomain.example.com must happen at subdomain.example.com
  3. The ACME server needs to check for a valid wildcard DNS entry for the requested domain before giving challenges to the client.

Thoughts? I'll start drafting a pull request today.

@diracdeltas

This comment has been minimized.

diracdeltas commented Mar 25, 2015

I attempted to address this in #97. @kentonv @titanous @hsivonen, please review if you have time.

@diracdeltas

This comment has been minimized.

diracdeltas commented Apr 8, 2015

According to certbot/certbot#66 (comment), IIS only supports one certificate per site, and a site may serve multiple subdomains. So either IIS will need wildcards or SANs (if the subdomains are known in advance and unlikely to change).

@iggy

This comment has been minimized.

iggy commented Jun 1, 2015

(After reading certbot/certbot#66 and not seeing it mentioned...) There are also performance implications to using certs with multiple SANs vs a wildcard. A cert with a wildcard is 1.9k. A cert with 50 SANs is 3.3k. A cert with 60 SANs is 3.5k. A lot of CAs I've dealt with cap the number of SANs on a specific cert to 50 because of this.

@EdHurtig

This comment has been minimized.

EdHurtig commented Jun 11, 2015

+1 to verification of the primary domain and a random sampling of the wildcard space that is unknown to the client. I don't have an opinion or a good argument for DVSNI vs. TXT records at the moment, but both seem like viable options. I would really like to see this in Let's Encrypt as wildcard certs make ops life so much easier

@bifurcation

This comment has been minimized.

Contributor

bifurcation commented Jun 26, 2015

I think the right way to address this is not at the level of challenges / authorizations. Instead, we should handle this at the level of certificate issuance -- if the server considers the client authorized for github.io, then it MAY, according to its policy, consider the client authorized for *.github.io.

bifurcation pushed a commit that referenced this issue Jun 29, 2015

Richard Barnes

@bifurcation bifurcation closed this Jul 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment