On Thu, Jan 11, 2018 at 04:49:45PM -0800, 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.
Note that method 10 definition seems to require the name to be validated to appear in the certificate. The name appearing in either the request or response is also required for validation to be deputizable (and I regard any non-deputizable validation to not be proper domain validation; both HTTP-01 and DNS-01 are deputizable). And I guess the reason why there is no blind echoing of ALPN has more to do with the horrible breakage rates it would cause (due to HTTP/2). Also, even if one used the name to be validated in the SNI, there is still a concern that there is some horribly broken hoster, that: - Allows claiming arbitrary https name, even if there is existing http site there (apparently these exist). And, - Allows claiming arbitrary ALPN values. Note that there is no requirement to be able to serve different certificate for given ALPN, because other ALPNs are not checked, so those might have the spoofed validation certificate. AFAICT, these are not common. Most provoders that let one claim arbitrary names (which would make TLS-SNI vulernable) do not let one claim name in use for http. And I suppose provoders that let one claim arbitrary ALPN values without forwarding the entiere connection are extremely rare (also, any such setup would need off-band signaling for ALPN, e.g., via PROXY/HAPROXY protocol). With "squatting" for SNI, one obtains weaker security bounds, as this drops the "even if" condition. So any provoder that is vulernable to TLS-SNI misissuance and lets one claim arbitrary ALPNs (and then presumably signals those off-band). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
