[squid-users] Proxy chain question

[Lucas van Braam van Vloten]

Hi,

Thanks for your extensive replies, it really boosts my understanding of
Squid :-)

> No, because Squid is only aware of two ways to send request - either a
> connection going to the TMG, or a connection going out directly on
port
> 443 to the server (bypassing the TMG). That latter is forbidden by
> firewall rules I presume, and the connection to the TMG is not secured
> for use with https:// URLs.

Hmm, bummer. I understand your point.
I wonder if it is possible to work around this limitation. It seems like
it is going to look ugly - but for now I am just exploring
possibilities.

For example, would it be possible to use two Squid instances, one to set
up the https connection ("directly" to the internet webservice) and the
second acting as forward proxy to relay all requests from the local
server through the TMG proxy? If some sort of "catch all" configuration
is possible on the second instance, the first instance does not need to
know it as a peer - if you know what I mean.

Alternatively, is it conceivable to use the iptables firewall on the
Squid box (running on RHEL 6.6) to relay traffic through the TMG? So
that Squid would not need any knowledge about this peer, and effectively
thinks it talks directly to the webservice (as required for TLS).

Thanks,
Lucas


> In the case where the browser client is sending HTTPS to Squid as a
> forward proxy it does so using CONNECT requests. Squid is able to
relay
> those CONNECT messages to the TMG and you see it working as the tunnel
> spans both hops and they are both blind to the HTTPS messages
themselves.

-----Original Message-----From: Amos Jeffries <squid3 at treenet.co.nz>
To: Lucas van Braam van Vloten <lucas2 at dds.nl>,
squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Proxy chain question
Date: Sat, 23 May 2015 15:53:25 +1200

On 23/05/2015 1:49 a.m., Lucas van Braam van Vloten wrote:
> Hello,
> 
> Thanks for your reply.
> 
>> Any particular reason?
> Unfortunately this double setup is not my choice, our architects
> prescribe use of the TMG proxy as mandatory for all internet access from
> the internal network. No exceptions.
>> Since the TMG is a reverse-proxy (...)
> This is true only for inbound traffic coming from internet; TMG acts as
> a forward proxy for outbound traffic.
> 

Ah. Okay.

> So the updated diagram for what I am trying to accomplish would be
> something like this:
> 
>                http       https       https
> Internal client ->  Squid  ->   TMG    -> internet webservice
>                   (reverse    (forward    
>                    proxy)      proxy)
> 
>> Squid will not be able to handle this either unless it is directly
> connecting to that service without the TMG in the way.
> 
> I noticed that if I configure the Squid proxy as a forward proxy and the
> TMG as its peer, I can initiate and authenticate a secure connection to
> the internet web service from a browser in the local network (using the
> squid proxy). Apparently the TMG is passed transparently and TLS is
> terminated on the webservice. Intuitively I would assume that,
> therefore, there should also be some way to initiate a https connection,
> and handle the certificate authentication, from the squid server itself.
> 
> Considering the updated diagram, do you think this can be done in Squid?

No, because Squid is only aware of two ways to send request - either a
connection going to the TMG, or a connection going out directly on port
443 to the server (bypassing the TMG). That latter is forbidden by
firewall rules I presume, and the connection to the TMG is not secured
for use with https:// URLs.

In the case where the browser client is sending HTTPS to Squid as a
forward proxy it does so using CONNECT requests. Squid is able to relay
those CONNECT messages to the TMG and you see it working as the tunnel
spans both hops and they are both blind to the HTTPS messages themselves.


If you could TLS encrypt the connection to the TMG Squid could send the
HTTPS messages inside that, but then the TMG would still be the agent
doing the final client-cert bits with the origin server.

Amos