Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi <[e-mail]>]

On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson <[e-mail]>
wrote:

>
> Ryan Sleevi <[e-mail]> 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.