[squid-users] Proxy chain question

[Lucas van Braam van Vloten]

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)

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

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.
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

=====================

My client makes a direct connection to the squid proxy (http) and the
squid proxy connects directly to the internet web service (https) and
handles all the SSL stuff.
However, this does not seem to work. I don't know how I can configure
squid to still use the TMG proxy to access internet.
In addition, I wonder if it is possible to limit access to this, and
only this, specific proxy function to only 1 host. All other reverse
proxy configurations on the server should be accessible to other
clients.

I hope someone could give me some advice...

Thanks!
Lucas

[Amos Jeffries]

Post by Lucas van Braam van Vloten
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.

Post by Lucas van Braam van Vloten
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.
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.

Post by Lucas van Braam van Vloten
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.

Post by Lucas van Braam van Vloten
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.
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
(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
=====================
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

[Lucas van Braam van Vloten]

Hello,

Thanks for your reply.

Post by Amos Jeffries
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.

Post by Amos Jeffries
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)

Post by Amos Jeffries
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 <***@treenet.co.nz>
To: squid-***@lists.squid-cache.org
Subject: Re: [squid-users] Proxy chain question
Date: Fri, 22 May 2015 15:18:30 +1200

Post by Amos Jeffries
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.

Post by Amos Jeffries
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.
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.

Post by Amos Jeffries
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.

Post by Amos Jeffries
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.
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
(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
=====================
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

[Amos Jeffries]

Post by Lucas van Braam van Vloten
Hello,
Thanks for your reply.

Post by Amos Jeffries
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.

Post by Amos Jeffries
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.

Post by Lucas van Braam van Vloten
So the updated diagram for what I am trying to accomplish would be
http https https
Internal client -> Squid -> TMG -> internet webservice
(reverse (forward
proxy) proxy)

Post by Amos Jeffries
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

[Lucas van Braam van Vloten]

Hi,

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

Post by Amos Jeffries
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

Post by Amos Jeffries
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 <***@treenet.co.nz>
To: Lucas van Braam van Vloten <***@dds.nl>,
squid-***@lists.squid-cache.org
Subject: Re: [squid-users] Proxy chain question
Date: Sat, 23 May 2015 15:53:25 +1200

Post by Amos Jeffries
Hello,
Thanks for your reply.

Post by Amos Jeffries
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.

Post by Amos Jeffries
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.

Post by Amos Jeffries
So the updated diagram for what I am trying to accomplish would be
http https https
Internal client -> Squid -> TMG -> internet webservice
(reverse (forward
proxy) proxy)

Post by Amos Jeffries
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

[Amos Jeffries]

Post by Lucas van Braam van Vloten
Hi,
Thanks for your extensive replies, it really boosts my understanding of
Squid :-)

Post by Amos Jeffries
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

Post by Amos Jeffries
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.

Post by Lucas van Braam van Vloten
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