[TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Tony Arcieri <[e-mail]>]

As I look at draft-huitema-tls-sni-encryption[1], 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
cases.

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
Internet.

More tangibly, I would like the following as the administrator of an
internal network:

- All outbound traffic flows through centrally managed gateway hosts which
act as TCP proxies. Outbound connections to the Internet are otherwise NOT
allowed

- 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:

https://wiki.squid-cache.org/Features/HTTPS

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
encrypted traffic).

This approach is partly described in RFC 2817[2], 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[3], 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

[1]: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
[2]: https://www.rfc-editor.org/rfc/rfc2817.txt
[3]: https://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01

-- 
Tony Arcieri