* 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
