On Thu, Aug 10, 2017 at 2:23 AM, Martin Thomson <martin.thom...@gmail.com>

> 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:

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

Reply via email to