On 2014-01-17 02:38, G VM wrote:
----------------------------------------
Date: Thu, 16 Jan 2014 23:39:43 +1300
From: squid3
Either auto-configuration (WPAD/PAC) or traffic interception / MITM:
No client side configuration.
It sounds like you chose MITM over auto-configuration.
This is how the network
looks:
Code: Select all
client --- --- router/firewall --- internet
|
squid proxy
Your diagram illustrates the client intercepting themselves. When
actually it is the firewall doing the interception then the router
handling the packet to/from the proxy.
See the nice picture at
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat.
I believe I didn't explained this clearly. The "image" might have been
messed up in the mail client which made it less clear.
The proxy is actually in a star topology with the client and the
router/firewall.
The | and "squid proxy" should be more to the right. The proxy,
router/firewall and client are on the same physical network(Layer 2).
The client has it's gateway to the squid proxy(gateway configured
through DHCP; autoconfig with DHCP didn't work as most browsers don't
support it). The squid proxy is the machine with the rdr rules.
The squid proxy has the router/firewall as gateway.
So the router/firewall doesn't intercept the connections first.
Okay good.
<snip>
The Squid proxy server will then set up its
own connection to the webserver with its own IP.
That describes only the "intercept" option behaviour.
Ok. What about the TPROXY behavior. It spoofs the IP of the client.
Does that mean that the client just has a connection with the
proxy(while it thinks it's connected to the webserver) and the proxy a
connection to the website (while the website think it's the client)?
And that this creates some sort of "tunnel" between client and website?
No tunnels.
Therefor
No "therefore". You have now changed topic from packet interception to
TLS/SSL interception. Different beasties.
this won't work with HTTPS as it can't see the packet contents unless
you use SslBump. SslBump creates a secure connection with the proxy
server, which in his turn creates an SSL connection to the webserver.
So
this is a man-in-the-middle.
NAT Interception is a MITM, so is TPROXY Interception and so is
Ssl-bump
interception. All three different interception/MITM mechanisms.
Ok. What I was actually wondering is if I need SSLbump in all cases
for HTTPS(if I want to filter on domainname in an acl and what if I
leave this domain name filter out).
Because of this reason and you need to
install a root certificate in the client browser I would like to have
another method.
That is only relevant to port 443 and ssl-bump mechanism.
Well I don't want only access to half of the internet ;)
So it's still relevant in my case.
Sure, but keep them separate in your thinking because they are different
layers in the network.
Maybe the OSI layering model would help here
(http://www.escotal.com/osilayer.html).
In this diagram NAT ("intercept" / rdr) operates solely at layer (3),
changing the packet IPs to one that will get delivered to the Squid
process.
TPROXY operates a little bit at each layer 2-4, taking the packet out of
layer-3 based on layer-2 details and passing it to a layer-4 socket
which will reach Squid.
HTTP/1.x contains a mix of all layer 5-7 operations.
SSL/TLS is more like a sub-layer between 4 and 5 on port 443 traffic. It
is performed by Squid on top of whatever layer 1-4 mechanisms are in use
but separate and underneath HTTP mechanisms.
From
what I understand TPROXY can accomplish this(however not sure how
squid
will check then which domain name is accessed).
Domain details are in the HTTP message. Which is processed the same to
locate it regardless of mechanism.
If I understand it
correctly TPROXY acts as the client (sending IP packets to the
webserver
with the client's IP).
Nope. Squid acts as a client. Always.
TPROXY *spoofs* the client IP for outgoing TCP connections.
Ok. Clear. So if I get this right TPROXY won't give me(in my setup)
any advantage over intercept(the router/firewall to the internet does
masquerading; otherwise TPROXY would give the advantage that IP based
authentication would work).
Essentially. It comes down to whether you want to get rid of that NAT or
not.
It's not clear if the client will still have an
SSL connection to the proxy server or not (I would think it still
has,
as otherwise the client should be aware that it has to sent requests
with https:// just in cleartext to the proxy, which is not secure,
and
this doesn't seem very "transparent" anymore).
Does TPROXY still need
SslBump configured?
TPROXY and ssl-bump are not related other than both being ways to
intercept traffic.
But sslbump is necessary for making HTTPS work anyway(as you say Squid
always acts as the client so squid actually sends the request to the
webserver), right?
Yes.
As there is no man-in-the-middle here I would think
domain names in requests can't be seen and squid can't react
accordlingy
to it.
MITM is the category of operation being performed. It covers all
operations where the client and/or server is being deceived as to the
proxies existence.
If the latter is the case, what are the pros for using TPROXY? In the
end the packets still have to go through your Squid server where they
can be intercepted.
TPROXY avoids the need for NAT packet mangling and all the security
problems which come with it. At the beginning TPROXY was also the only
way to cleanly do interception for IPv6 traffic, that has now changed.
Not sure what you mean by "NAT packet mangling". And with security
problems you mean eavesdropping in the packet?
No I mean:
* external parties being able to do "NAT busting" to penetrate through
the firewall rules by detecting an existing NAT'ed connection.
* obfuscation of connection details for tracking down any bad behaviour
after the fact.
* and upper-layer protocol issues in HTTP, FTP and SIP (such as
demonstrated by CVE-2009-0801).
Is there any article or reference you have where these problems are
explained and how TPROXY fixes this?
TPROXY does not alter the packets, so there are no NAT records to be
"busted" and all packet information is available for tracking and record
keeping. Whatever security you apply to the client will work regardless
of whether the proxy and TPROXY rules are present or not with no special
cases for pre/post NAT IP addressing. Simpler security rules are more
manageable and usually safer.
Anyway
I configured PF. I read that I need ipdivert.ko which is available in
my kernel and need divert-to rules for using TPROXY.
I got squid running with Intercept using the rdr rules:
rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 443
-> 127.0.0.1 port 3129
rdr pass on $lan_if inet proto tcp from 192.168.1.32 to any port 80
-> 127.0.0.1 port 3128
However for TPROXY I should use divert-to right?
pass in quick log on em0 proto tcp from 192.168.1.32 to any port 80
divert-to localhost port 3128
pass in quick log on em0 proto tcp from 192.168.1.32 to any port 443
divert-to localhost port 3129
The Squid site actually has an article about squid with PF and
TPROXY(however specific for OpenBSD).
When using the rules provided there I get an error that divert-reply
isn't valid on freebsd.
I'm not sure if letting this divert-reply rule out (which removes the
warning of course) doesn't need another rule to replace that
functionality.
Okay. As you said that was for OpenBSD, which has a quite different
version of PF.
There is one for FreeBSD
(http://wiki.squid-cache.org/ConfigExamples/Intercept/FreeBsdPf).
It is a bit old now so you may still have a bit of trouble, any updates
you can make to ensure it works on current FreeBSD are welcome.
Please
correct me if I'm wrong at any point. It would greatly increase my
understanding of the matter and probably help in solving issues. What
way should I go here to get the explained goal?
Get it going with just port-80 for starters. Once that is done add
identical PF and routing rules for port-443 before you start with
ssl-bump pieces in squid.conf for the SSL/TLS protocol layer.
Ok. I got it working with intercept for both HTTP and HTTPS and the
rdr rules in Freebsd PF.
I'll try to do the same for HTTP with TPROXY first.
From all what I've read here, it seems that anyway I configure squid,
something has to be done on the client.
Either
- auto-configuring (which should still be picked up by the client)
- configuring the browser to use a proxy
- configuring the browser to add a root certificate
Yeah. No magic bullet sorry.
Amos
