[squid-users] Behind enemy lines (squid behind proxy)

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/11/2014 11:30 a.m., doc.holliday at usa.com wrote:
> 
>> Sent: Wednesday, November 05, 2014 at 10:48 PM From: "Amos
>> Jeffries"
> 
>> On 6/11/2014 2:33 p.m., doc.holliday wrote:
>>> 
>>> I've searched through the internets and tried various things...
>>> to no avail. Hopefully someone here can point me in the right 
>>> direction. I am sitting behind a proxy, which accepts
>>> http/https. Everything else is blocked. If I instruct my
>>> browser to use this proxy, everything works dandy. Both http
>>> and https. The problem is, I have a few apps that don't have an
>>> option to set proxy. So, my idea was to set up squid on the
>>> local machine that would transparently redirect http/https to
>>> the proxy. Eg something like this: [ local_box: app (http or
>>> https) ---> squid ] -----> [ the_proxy ] -----> ... -----> [
>>> internets ] I have no control of the proxy, nor do I know what
>>> goes on after it.
>> 
>> What you have configured forces that not to happen then sends
>> the de-crypted traffic to the peer proxy as HTTP. The peer is
>> rejecting the un-encrypted protocol containing https:// URLs with
>> a 503 for whatever reason.
>> 
>> If the other peer is another Squid then chances are still fairly
>> high that it has been built without OpenSSL support and so
>> literally cannot open the TLS connection to deliver the https://
>> request to the origin.
>> 
>> Generating new CONNECT tunnels over peer proxies has not yet
>> been coded for Squid. Nobody seems willing sponsor its
>> development, despite all these problems bumping is now causing.
>> 
>> Amos
> 
> Thanks Amos. It makes sense... mostly. :)
> 
> One thing I am wondering though is, if I set my browser to use the
> proxy (in the browser settings) for both http and https, both work
> fine. So, it seems the proxy server supports both http and https
> over CONNECT tunnels.

That is all just HTTP. The HTTPS is just a sequence of bytes inside
the CONNECT tunnel "payload". When the browser generates the
CONNECT+TLS parts your proxy can relay the CONNECT message as-is to
the peer, which needs not understand the HTTPS in any way to pump it
as raw TCP bytes to the origin.

Generating new CONNECT+TLS wrappers from scratch to secure a TCP
connection is what Squid does not yet do. It's completely possible,
just nobody has done (or sponsored) the implementation work yet.

> 
> So, if the squid on the local_box is not talking to the_proxy (it's
> cache_peer) via CONNECT, what does it use?

Squid talks to peers using HTTP on top of either TLS or TCP. When TLS
is used its called "HTTPS" regardless of whether the peer is a proxy
or origin. HTTP messages with https:// URLs are only permitted to be
sent over TLS.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUZD9XAAoJELJo5wb/XPRjId8H/RxjTtJ8k3ephVIF62bMoz5F
8TCkK9f71XDoSTrot7R8c05tbtlO+Erg8o7xGxIU7XsQqXoGWVkZYysp/R4DB1Ox
0cYPxG3gYdMNEKcjk3Nwgv+8RPpgq/q6cnhPG5Y0kHX8V0eZ3CNQooVLu26dulno
QfwJlswILfDavaJZ8jvHklIHCKsscuzHT653EGd7WYzf6TpV3slaPhJ/JcGeQo4Z
RyTeJLaL2Vk3OhQ2tfnMtTIpaGC5FF1rNztfat8bzAzHZtLZMHRpKkrKcM6SsV5p
9sjLCEr4KUd/ruqO9WajbJ7+JHNX17444/s5HTljNSeI8zqR/Xm1lMLQVCcN2Bo=
=mVP4
-----END PGP SIGNATURE-----