Ryan Sleevi <[email protected]> wrote: > 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.
okay, I'm with you so far.
> 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.
To do this requires that the cloud provider make a clear decision about what
they are going to do with SNI-less requests above. I feel that the cloud
provider did something wrong here.
> 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.
I see.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
