So you want CONNECT for TLS? You could have said that. What makes you think that the implementation story here would be any different? I'm not trying to destroy your idea, which seems fine on face value, but just trying to understanding the value proposition better.
On 11 August 2017 at 00:03, Tony Arcieri <basc...@gmail.com> wrote: > On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson <martin.thom...@gmail.com> > wrote: >> >> 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. > > > Backing up a bit: my personal primary use cases are services running on a > network trying to speak outbound. Yes it's great browsers have support, but > what about anything else that wants to make an outbound TLS connection to > the Internet? > > Trying to solve this problem with HTTP, rather than the TLS, forces every > single network client library on earth that wants to talk through these > proxies to implement both CONNECT and enough HTTP to speak to the proxy and > request CONNECT. > > Do you really think (ab)using an HTTP proxy this way is a good idea? I > don't. I also don't think it's been particularly successful: > > - We've wound up with a server-side ecosystem where, as far as I can tell, > Squid is the only service which implements all the features needed to > provide an HTTPS-authenticated outbound CONNECT gateway with > client-by-client ACLs > > - Support is not as ubiquitous as you may think. For example Go's net/http > library does not support CONNECT through an HTTPS proxy: > https://github.com/golang/go/issues/11332 > > Solving this problem with TLS instead of HTTPS could result in a solution > where once it's implemented in a TLS library, any clients using that TLS > library could take advantage of it, rather than each client having to > implement CONNECT themselves. > > I say this all as someone looking at rolling out Squid for this purpose as > we speak, and having worked places who have run Squid this way in the past. > CONNECT is widely supported enough to mostly make this work, but I think > things could be... much better than they are. > > -- > Tony Arcieri _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
