On Sun, 31 Jan 2016 03:39:25 +0000 Hugo Landau <[email protected]> wrote:
> A proposed scheme for wildcard support. > <https://github.com/ietf-wg-acme/acme/pull/74> 1. I don't think ACME should support wildcard characters anywhere but the leftmost label. RFC6125 says TLS clients SHOULD NOT match wildcards in other labels, and in practice neither clients nor CAs support them. 2. The validation mechanism is insecure when a domain allows users to register arbitrary sub-domains and host content on them (e.g. github.io, Amazon S3). For example, if I create a wildcard authz for *.github.io, the server will issue challenges for some random sub-domains (e.g. df2icxw7mg5gbbfc636ttbwsmi.github.io, fonm6ymv77dlpac2qfvyjns4u4.github.io). I can go register those sub-domains at github.io (since the sub-domain labels have high entropy, they will be available with high probability), complete the challenges, and then be authorized for all of *.github.io. To fix this, the server should also require I complete a challenge for the "underlying" identifier (github.io in this example). 3. It's not specified how the server communicates to the client what sub-domains need to be validated. I suggest that the HTTP, DNS, and TLS SNI challenge objects be extended to include a "hostname" field, which specifies the hostname under which the challenge must be completed. The server can then make use of the existing combinations mechanism to require the client complete challenges under several sub-domains. Perhaps ACME shouldn't even specify how wildcard identifiers are validated, but leave it as a matter of CA policy. Some CAs might be fine only requiring a challenge on the underlying domain (which is how some CAs currently validate wildcard certs), while others would require challenges on random sub-domains. The policy might even be different depending on challenge type: the CA might accept either a single DNS challenge on the underlying domain, or a combination of HTTP challenges on the underlying domain and several random sub-domains. -- Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
