If you are using a new protocol, all of the concerns Peter have come into play. If you are there, why wouldn't you do the challenge validation within the new protocol rather than using the certificate (which is sent in the clear in current TLS versions). That might be easier to implement than generating the self-signed certificate...
On Fri, Jan 12, 2018 at 2:06 PM, Roland Bracewell Shoemaker <rol...@letsencrypt.org> wrote: > I'm actually going to roll back my thoughts on the SNI value. Thinking > about this more I think it does actually make sense to revert to using > the actual host name here. > > In the initial design of the TLS-SNI challenge the XXX.acme.invalid > value was used as a way to allow servers to dynamically serve both > regular and validation traffic. Since we would be using ALPN here we no > longer need a special SNI value in order to differentiate validation > traffic from regular traffic so this token value is no longer needed. > > If we change that I think we can also remove the need to compute a pair > of SAN values for the cert contents. The original purpose of this was to > prevent a 'dumb' client from simply constructing a certificate on the > fly by sticking the SNI value it received into the SAN and automatically > allowing validation of anything that hit it. If we switch to using the > host name in the SNI then this is no longer necessary as the token value > is no longer present in the request. > > If we make these changes I think the challenge would be different enough > that at that point it should probably be given a completely new name in > order to differentiate it from the original TLS-SNI challenges. I'd > suggest the incredibly imaginative TLS-ALPN (or tls-alpn-01). > > On 01/11/2018 04:49 PM, Roland Bracewell Shoemaker wrote: >> This seems like a silver bullet for the problems we’ve been seeing. Given >> that blindly responding to an unknown ALPN value would be an RFC violation >> this seems safe (although, hey, who knows what servers/cloud providers >> actually do). Definitely interested in the results of the scan. There could >> still be some argument about ‘misuse’ of the SNI extension but unless we >> have a concrete reason to the host name being validated I’m not sure I’m >> convinced we should. >> >> Does anyone have any objections/spot any major issues with doing this? >> >>> On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg <jonat...@titanous.com> >>> wrote: >>> >>> As many of you are probably aware, Frans Rosén of Detectify discovered a >>> method of exploiting many shared hosting providers to obtain unauthorized >>> certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt >>> is in the process of removing support for these challenge types[1]. >>> >>> Obviously this is not ideal, as the TLS-SNI challenge is useful in a >>> variety of use cases. The good news is that TLS-SNI-02 appears to be >>> fixable. >>> >>> In order to get the ball rolling on a fixed version (aka TLS-SNI-03), >>> here’s a straw proposal, based on something originally publicly suggested >>> by Ryan Sleevi[2]: >>> >>> Start with the TLS-SNI-02 challenge specification, and add the requirement >>> that the ACME server MUST send an ALPN extension in the ClientHello with a >>> single “acme” protocol name, and the ACME server MUST confirm that the >>> ServerHello also includes an ALPN extension with a single “acme” protocol >>> name. >>> >>> The only concern I’ve seen about this is the theoretical possibility that >>> servers might just repeat back the ALPN extension with the same protocol >>> name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or >>> similar) to see if this behavior exists in the wild. >>> >>> Jonathan >>> >>> [0] >>> https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 >>> [1] >>> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 >>> [2] >>> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html >>> _______________________________________________ >>> 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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
