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.
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?
Thanks,
Lucas
-----Original Message-----From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Proxy chain question
Date: Fri, 22 May 2015 15:18:30 +1200
On 22/05/2015 4:58 a.m., Lucas van Braam van Vloten wrote:
> Hello list,
>
> In my network I have a Microsoft TMG proxy server for http(s) access to
> internet.
> This TMG server also serves as a reverse proxy to channel incoming
> traffic to a Squid reverse proxy in the internal network (yes, two
> reverse proxies in a line)
Any particular reason? It may prevent Squid being able to do what you want.
>
> This Squid server is currently configured as a reverse proxy to allow
> traffic from internet to a number of webservices that run on an internal
> server.
>
> Now I want to add a function to the squid server, in addition to the
> existing function. It should serve as a proxy to allow a client on the
> internal network to access a web servoce on internet.
> So, put simply, the traffic goes like this:
> Internal client -> Squid Proxy -> TMG proxy -> internet webservice
>From that diagram I'm a little doubtful that reverse-proxy is the right
way to do it here. Proxy at the client end of the connectivity are
usually forward- or interceptor- proxy.
>
> The reason to use this configuration is because the internet webservice
> requires a client certificate for authentication, and TMG is not able to
> handle this.
Squid will not be able to handle this either unless it is directly
connecting to that service without the TMG in the way.
Because TLS is point-to-point security protocol, any proxy agent in the
middle must terminate the clients TLS and start its own server
connection for the next hop. Squid does not (yet) support sending
CONNECT over a peer proxy to bypass the TMG.
So in your current setup Squid sending the client cert will be sending
it to to authenticate with the *TMG* - not the web service.
> So now I am trying to configure this on my Squid server. I wish to make
> my configuration as restrictive as possible. But I am new to the Squid
> configuration, and I could use some help.
>
> So basically, I want the following:
> 1. The client makes a http connection to my Squid proxy
> 2. The Squid proxy initiates the client certificate authenticated
> connection to the internet webservice
> 3. The connection from the Squid proxy to Internet uses the TMG proxy.
>
> I do not wish to use any form of caching on my Squid server.
>
> I considered using a configuration similar to my reverse proxy
> configuration, using the following structure:
> (this configuration works)
>
> =====================
>
> # Designate a port and SSL config for this specific webservice
> # Local server IP is 192.168.0.1, traffic comes in through the TMG
> https_port 192.168.0.1:1443 accel
> defaultsite=webservice.exposed.address.com vhost <SSL stuff>
>
> # enforce use of https
> acl webapp_SITES dstdomain webservice.exposed.address.com
> http_access deny HTTP webapp_SITES
> http_access allow webapp_SITES
>
> # Configure the reverse proxy for clients that connect to the external
> (exposed) address
> acl webapp_URL url_regex ^https://webservice.exposed.address.com
> cache_peer internal.server.lan parent 8080 0 no-query no-digest
> originserver login=PASS name=webservice_APP
> cache_peer_access webservice_APP allow webapp_URL
> cache_peer_access webservice_APP deny all
>
> =====================
>
> So if I use this for my new purpose, I assume that the cache_peer would
> be the internet webservice address, and I could use the sslcert option
> to make it use the client certificate. Something like this:
>
> =====================
>
> http_port 192.168.0.1:8080 accel defaultsite=squid.server.lan vhost
> acl webapp_URL url_regex ^http://squid.server.lan
> cache_peer webservice.somewhere.on.internet.com parent 8443 0 no-query
> no-digest originserver sslkey=/path/to/ssl/key name=webservice_APP
> cache_peer_access webservice_APP allow webapp_URL
> cache_peer_access webservice_APP deny all
>
> =====================
That is the correct way to do it outbound from Squid. But the catch as
mentioned above is where the TLS link gets terminated (the TMG or the
web service).
Since the TMG is a reverse-proxy the DNS records for the cache_peer
domain name points at the TMG instead of the Internet service. You have
to have the cache_peer directly going to the server which uses/requires
the client certificate. Which means using IP or if available the
services own host name to avoid the TMG.
Which cycles back to that first question I had at the top about why the
TMG exists at all. You may or may not be able to do this without a full
topology redesign.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
