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

[Martin Thomson <[e-mail]>]

I'm trying to work out whether there is anything new here.  I know
that browsers implement proxying over HTTPS and CONNECT.  Can you
summarize the ask more succinctly?  Because I'm thinking that this is
a solved problem.

See Section 8.3 of RFC 7540.  We didn't put that there for a lark.

On 10 August 2017 at 15:54, Tony Arcieri <[e-mail]> wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>