On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell <[email protected]> wrote:
> Hello, > > Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an > SNI value with the in-addr/ipv6.arpa domain name corresponding to the > iPAddress being validated MUST be specified. I have a concern that this > requirement suffers the same problem that rendered tls-sni-01 insecure: > namely, an arbitrary user on a shared hosting provider could upload an > arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus > circumventing any security provided by the mandatory SNI extension. > > The mandatory ALPN extension prevents this from being exploited to obtain > fraudulent certificates, but given how trivially the SNI requirement can be > defeated in the same manner as for tls-sni-01, I don’t believe that > requiring SNI provides any security value and is not necessary. If the > intent for requiring the SNI extension is to convey to the TLS server that > an IP address is being validated, couldn’t that similarly be accomplished > by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames) > requires that a SNI value be specified, so TLS servers could differentiate > between challenge requests for dNSNames and iPAddress based on the presence > (or absence) of the SNI extension. > I’m not sure I follow the attack scenario you’re describing.. The value proposition of the ALPN method is that it’s indicative that the server does not “suffer the same problem that rendered sni-01 insecure”, precisely because it does not allow an arbitrary user to upload an arbitrary certificate while also responding with that ALPN identifier. Perhaps I misunderstood your question, but with the above invariant being the reason for the introduction of the ALPN method, if we assume it holds, do you still have concerns? >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
