On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara <[email protected]> wrote:
> On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > > > I agree this approach will limit compatible TLS servers but luckily > > > HAProxy should be fully compatible. > > > > > > Alas, there's nothing like hitting send on a message to a mailing list to > > make you think a little bit harder. > > > > I overlooked the fact that it doesn't seem possible to select the > > certificate based on the ALPN, just the backend. That's not really the > > primary difficulty at hand. I suspect matching the request to the `bind` > > with the correct alpn is still going to be problematic if the server > needs > > to respond to requests for the real identifier with both a certificate > and > > a challenge response certificate. > > > > I would be happy to be corrected :-) > > Basically, for security, one needs to put the domain to be validated to > the SNI field. Not doing that was the reason for the TLS-SNI-01/02 > vulernability. > > AFAICT, the hard constraints are: > > - No taking site offline when validating. > - The validation certificates are not publically trusted. > - SNI needs to be set to the domain being validated. > - Compliant with reasonably strict reading of "10 methods" (which > essentially impiles the third point and using certificate to > transmit data). > I'm less worried about this constraint. If there's consensus for a change, changes can be made to the BRs much more quickly than an RFC can be issued. > > (I do not consider compatiblity with present software a hard > requirment). > > > Few ways that come to mind: > > - Have "acme" ALPN and send validation certificate for that. > - Have some new TLS extension and send validation certificate for that. > My inclination here would be to do the whole thing in a TLS extension: Have the client send its value in an extension, and have the server respond in an extension. It's what they're there for. You would need upgrades to TLS stacks and new API for this, but IIRC, QUIC is going to require some similar changes to make applications aware of extensions anyway. (Cf. https://github.com/bifurcation/mint/pull/137 for EKR's minq implementation of QUIC) Any approach that relies on overloading an existing TLS field make me nervous. If the field is there for some other purpose, then it seems inevitable that you'll run into bugs of more or less the character we've hit two times already. --Richard > - Have "acme" ALPN, establish data link and exchange an exported > authenticator request/response over it (response carries an X.509 > certificate). > > > One also wants as good assurance as possible that the entity > terminating the TLS link approves the certificate. This entity may be > the applicatnt themselves (e.g., applicant's VPS with direct IP- > layer connectivity, or with SNI-level routing of unterminated TLS > connections), or it might not be (shared hosting). > > The first and second method are much better there than the third > (any provoder that lets users claim ALPN protocols runs into trouble). > And of the first two, the second would be slightly more safe, but > probably not enough for it to be worth trouble. > > > However, one should keep in mind that if hosting provoder allows > claiming https hosts regardless of http ones (some provoders have > problems of this sort[1]), they would probably also approve the > certificate requests for the owner of the https host. > > > [1] The Detectify article started with one unnamed such provoder > I think it would have been easy to find a CA that would have > validated the domain as-is, and it was only due to author's fixation at > using LE that the TLS-SNI issue was discovered. > > > > -Ilari > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
