On Thu, Oct 10, 2019, 8:54 AM Salz, Rich <rs...@akamai.com> wrote: > > - I want to keep the SNI encrypted in TLS hops that use client > certificates, but where ESNI won't work. > > > > I have some questions about this, see below. > > > > - For example, how is the SNI transmitted in the parens here: > > > > - [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin > ] > > > > It is transmitted in the clear. There is no architectural reason why it > could not be ESNI. But in my experience, there’s not much point in it, > either. > > > > What do you mean by client cert? The CDN->Origin hop cannot present > original Client’s certificate because (in general, maybe there are some > exceptions) the CDN does not have the private key so it cannot do the > necessary crypto operations. That’s the right thing to do, otherwise > anyone could present any client cert and claim to be the Client. Instead, > the Client certificate (or parts of it such as the subjectDN) are presented > in newly-added HTTP headers. The origin is configured to trust those > headers, depending on the CDN/Origin relationship – it could be the CDN has > it’s own client cert, it could be via IP filters, etc. > > > > - I don't think a DNS-based solution like ESNI will work for that > second hop, because the origin tends to be identified by an IP address > rather than a domain name. > > > > In our experience, the origin is identified by a DNS name. I could > double-check, but I don’t think **any** of our customer origins are > identified by IP address. >
At least one customer of the CDN I work for (namely my own website) uses an IP address. Shared hosting behind a CDN does exist where clients of the service provider are signed up to the CDN, and it might be interesting to use ESNI there but the privacy risks are less extreme absent a global passive adversary. Protecting client to shared infrastructure is what ESNI aims to do. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
