On 16/01/2014 10:23 p.m., G VM wrote: > NOTE: this is an updated version of a mail that didn't go into the mailing list. > NOTE: the problems you are having understanding this is that interception of traffic is a highly complex subject best dealt with in small concept chunks and you are thinking of multiple concepts all at once trying to figure out something you have not mentioned yet. Comments and corrections inline ... > Hi all, > > I'm > currently experimenting with Squid. The idea is the following: An access control setup: > during > office hours you can only go to certain sites. Outside these hours you > can browse to whichever site you want. This is for specific IP(s) or IP > ranges/subnets. 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. > The > router routes packets for the client to the Squid proxy. The client has > the Squid proxy as the gateway. I have FreeBSD 9.2 on the proxy. Squid > 3.4 compiled from source with the --with-nat-devpf and > --enable-pf-transparent options. Firewall is PF. > Okay. > Somewhere in the > process I got confused with the different ways to configure Squid and > PF. No worries you have got lots of company there. ;) > I need intercept or TPROXY as http_port(s) option. Yes, the "or" is important there. > From what I > understand intercept will see packets that are for a webserver on the > internet through port 80. That describes port-80 pretty well. Both "intercept" and "tproxy" options handle that type of traffic. > 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. > 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. > 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. > > 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. > 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. > 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. > 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 > > From what I understand divert-to doesn't actually change anything to the packets. It just delivers the packet on another port.The > rdr rules rewrite the destination IP, Yes to both of those. > so No "so". these two parts of the sentence are unrelated facts. > the HTTP/HTTPS request has to > be read anyway to open a connection to the destination webserver. True, but is applicable to any TCP connection received by Squid. > > Might > it be crucial to have 2 interfaces to make TPROXY(or intercept) work > alltogether The two mechanisms do not play nicely together. I'm not sure what the PF implementation of divert-to does exactly, but on Linux at least the TPROXY mechanism takes SYN packets out of the network stack prior to NAT being applied to them so the SYN and following packets have different IPs and things break. If you are able to configure divert-to so that it works I recommend that with TPROXY. > 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. Amos
