On 26/05/2015 9:30 p.m., Lucas van Braam van Vloten wrote:
> 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.
We are slowly working towards having Squid able to generate CONNECT
messages for use over insecure peers. But that is still some ways off
and will only be in Squid-4 or later.
>
> 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).
There is <http://nocrew.org/software/httptunnel.html> which may help a
little if you can use it for port 443 outgoing from Squid.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
