Code change:
client's control of the domain by verifying that the TLS server was configured appropriately. <del> Compute the Z-value from the authorized key object in the same way as the client. </del> <ins> Choose a subset of the N DVSNI iterations to check, according to local policy. For each iteration, compute the Zi-value from the authorized keys object in the same way as the client. </ins> <del> Open a TLS connection to the domain name being validated on port 443, presenting the value "<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </del> <ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </ins> Verify that the certificate contains a subjectAltName extension <del> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid". </del> <ins> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid", and that no other dNSName entries of the form "*.acme.invalid" are present in the subjectAltName extension. It is RECOMMENDED that the ACME server verify a random subset of the N iterations with an appropriate sized to ensure that an attacker who can provision certs for a default virtual host, but not for arbitrary simultaneous virtual hosts, cannot pass the challenge.  For instance, testing a subset of 5 of N=25 domains ensures that such an attacker has only a one in 25/5 chance of success if they post certs Zn in random succession.  (This probability is enforced by the requirement that each certificate have only one Zi value.) </ins> It is RECOMMENDED that the ACME server validation TLS connections from multiple vantage points to reduce the risk of DNS hijacking

Related discussion:
text: The exact conditions for the vulerability vary: SimpleHTTP is vulnerable if no default vhost is set explicitly, the server accepts the "tls": true parameter as currently specified, and the domains served over TLS/HTTPS are a strict subset of those served over HTTP. DVSNI is vulnerable if no default vhost is set explicitly, and the hosting environment provides a way for tenants to upload arbitrary certificates to be served on their vhost. James Kasten and Alex Halderman have done great work proposing a fix for DVSNI: URL That fix also has some significant performance benefits on systems with many virtual hosts, and the resulting challenge type should perhaps be called DVSNI2. The simplest fix for SimpleHTTP is to remove the "tls" option from the client's SimpleHTTP response, and require that the challenge be completed on port 80. URL Alternatively, the protocol could allow the server to specify which ports it will perform SimpleHTTP and SimpleHTTPS requests on; HTTPS on port 443 SHOULD be avoided unless the CA can confirm that the server has an explicitly configured default vhost. The above diffs are currently against Let's Encrypt's version of the ACME spec, we'll be happy to rebase them against the IETF version upon request. [1] though I haven't confirmed it, it's possible that sites that attempted to set a default vhost are vulernable if they followed advice like this when doing so: URL ; an attacker need only sign up with a lexicographically lower name on that hosting platform to obtain control of the default. Peter Eckersley EMAIL Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993