On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson <[email protected]> wrote:
> > Ryan Sleevi <[email protected]> wrote: > > The latter only becomes a consideration if multiple IPs are > terminated > > at the same TLS layer, and that TLS termination layer doesn't > consider > > the destination IP when dispatching certificates. If we were to omit > > I am curious to understand the use case for offboard TLS termination by IP > address. That would seem to involve some kind of layer-3 (destination) > NAT. > Given that TLS would forbid SNI being present in that case, how would such > a > offboard TLS termination work? > Right. I wasn't trying to suggest that such servers intended to be responding on 'bare' IP addresses, merely that they were capable of doing so (by virtue of the SNI absence). As commonly configured by a TLS server, all IPs would merely be dispatched to a common 'default' host implementation, *unless* the server used some out-of-band signaling method to determine the 'original' IP. In the cloud provider model, this might be multiple physical IPs all dispatched to a same internal system. The internal system ACLs based on hostname (the original issue with the tls-sni proposal), and thus may not have ACLs on the 'bare hostname' form. Let's say I have 'good.example' (Customer A) resolving to 10.0.0.2, 'evil.example' (Customer B) resolving to 10.0.0.3, and whenever you connect, TLS termination is dispatched to an internal service on 10.0.0.1. Now, the system can already dispatched based on hostname, ensuring that good.example sessions are served Customer A's response, and evil.example sessions are served Customer B's response. The issue is whose response is served when there is no SNI? Under a TLS-ALPN (no-ip) model, there's no restrictions or requirements there; you could serve Customer A, customer B, or neither - and none would undermine the security of TLS-ALPN (as a validation method) or of the security properties you're trying for. In a world where IPs were possible to be validated using TLS-ALPN, and the information omitted from the request, if evil.example/Customer B can serve a certificate that confirms the response for 10.0.0.2, then they could get a certificate for Customer A's IP. In a world where we include the to-be-validated IP in the request, and the Cloud Provider is observing the security invariants required for TLS-ALPN (that any hostnames to be validated have been successfully authenticated as belonging to the customer in question), then Customer B would have to demonstrate control, to the provider, over 2.0.0.10.in-addr.arpa in order to get such a certificate.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
