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