As I look at draft-huitema-tls-sni-encryption, I really think it's
putting the cart before the horse. I really like the proposed TLS-in-TLS
tunneling mechanism, but I feel it is a generally useful mechanism, and
this draft relegates it to providing a point solution specifically for the
purposes of SNI encryption and considering only that use case.
One of the things I like the most about TLS 1.3 is how it has harmonized
the sort of chunky stew of ill-conceived features found in previous TLS
versions (with nebulous and overlapping responsibilities) into a smaller
set of clearly-defined parsimonious ones which cover a wide range of use
In considering the general problem of "SNI encryption", and particularly
within the context of TLS-in-TLS tunneling solution, I humbly ask that
other use cases which would benefit from a TLS-in-TLS tunneling mechanism
are considered. I think any draft about this should have TLS-in-TLS
tunneling itself as the centerpiece, and "SNI encryption" off to the side
as one potential use case.
So, what other use cases are worth considering? Egress proxies!
Consider: a gateway server acting as an external proxy which bridges an
internal network with the Internet, acting as a forward proxy to
authenticated clients (either human-driven apps/tools or backend services).
What I think is particularly interesting about this use case in the context
of the SNI encryption discussion is it is in fact almost entirely the same
problem from a technical perspective. Where it differs is largely in the
framing of the problem: instead of using the gateway to reach a hidden host
from the Internet, we are using the gateway to talk to the Internet from an
internal network which needs to go through a proxy host to reach the
More tangibly, I would like the following as the administrator of an
- All outbound traffic flows through centrally managed gateway hosts which
act as TCP proxies. Outbound connections to the Internet are otherwise NOT
- As we're fans of actually using TLS to provide end-to-end transport
security and not "SSL added and removed here ;-)", we want the resulting
connection to be encrypted end-to-end between the internal network TLS
client and the requested destination server. Also, all "setup"
communication to the gateway should also happen over TLS
- The gateway authenticates clients (using e.g. a TLS client certificate)
and authorizes the outbound hostnames against an ACL. This way we can
control which clients are allowed to reach which external endpoints.
There are a few additional things which are different between the cases
beyond some of what I've just mentioned. Ideally the client verifies the
gateway's server cert against an internal-only CA bundle, then verifies the
tunneled destination host against a public CA bundle. We might want a
client to present an internal client certificate to the gateway, but
present no cert/a different cert to the destination host. That said, aside
from minutia like that, the machinery seems largely the same.
What are the real-world "rough consensus and running code" solutions to
this sort of problem in place today? There are all sorts of options that
are sort-of-not-quite like what I just described, e.g. a SOCKS proxy. But
the one I'm thinking of as I write this is CONNECT tunnels:
These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish
outbound TCP connections (which, if you care about security, will carry TLS
This approach is partly described in RFC 2817, but to tick all of the
checkboxes on the points I mentioned earlier using this method, you need to
implement features in draft-luotonen-web-proxy-tunneling-01, which has
never received an RFC and, as far as I can tell, is only properly
implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems
less than ideal to me, and yet in many ways it seems like the "least
friction" option, especially for access control purposes.
I would really love a simple, straightforward approach to this problem with
a published RFC instead of an expired draft that's only implemented by
Squid. I also think TLS-in-TLS tunneling can solve this same problem in a
much more straightforward manner.
tl;dr: when making drafts regarding TLS-in-TLS tunneling, please consider
the forward-proxy use case in addition to the reverse-proxy case
TLS mailing list