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
