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

[doc.holliday at usa.com]

> Sent: Wednesday, November 05, 2014 at 10:48 PM
> From: "Amos Jeffries" <squid3 at treenet.co.nz>

> On 6/11/2014 2:33 p.m., doc.holliday at usa.com 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.

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

-D