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