Thanks so much for the explanation! I will try again to get more functionality out of squid as a transparent proxy. I will start with http_port 3128 # No Intercept, because you said port 3128 should not be used for NAT traffic https_3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB key=blabla cert=blabla Iptables will route all http client traffic to DG via port 8080, and https traffic to squid via port 3129. I will research configuring DG to handle https. I don't yet follow your traffic flow illustration, but I'll work on it :) Dev -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Wednesday, June 04, 2014 1:07 AM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: Cannot access google search results and other https sites through squid proxy. On 4/06/2014 6:28 a.m., Development Team wrote: > ... >> Note the need for separate forward-proxy and intercept-proxy >> listening > ports in Squid is a MUST. >> >> Forward-proxy is the better mode of operation, if you have clients >> already > using it leave them. Add the interception as a secondary http(s)_port > for the >clients that cannot be configured with the proxy. >> Amos > > This issue with ssl_bump has really been confusing me! If I have the > line > The basic idea is that each port has a different syntax for the traffic travelling over it. * Port 3128 has HTTP syntax for talking to a proxy, * Port 80 has syntax for talking to a web server, * Port 443 traffic is TLS encrypted, * Port 25 has syntax for email, etc. There are also other complications with interception systems changing TCP packets (or not): * NAT places Squid IP:port as the original destination IP:port and sometimes require extra work to look the real details up. * TPROXY sends the IP:port TCP values to Squid in client orrientation (inverted by type) There is a mode flag after the port number to tell it what the traffic syntax is and what packet mangling needs undoing. Then additional options to tune the processing behaviour. http(s)_port port mode options For legacy reasons the TLS/non-TLS packet encryption is part of the directive name. Either http_port or https_port. Is that clear? > http_port 3128 ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=4MB cert=bla.crt key=bla.key intercept This one should have the "intercept" at the front since it is the mode: http_port 3128 intercept ... It tells Squid the traffic is arriving from a NAT system in port 80 syntax. There are a bunch of extra security checks, formatting changes, etc which Squid is required to do on this traffic before it will work. If you pass any non-NAT traffic at it, or in formats other than port 80 syntax these extra checks and modificatios will break the transaction. > > Then squid will not start unless I also have an additional config line > like > > http_port 3129 This one means Squid accepts traffic in port 3128 forward-proxy HTTP syntax. BTW: port 3128 is the port registered officially for forward-proxy traffic. It is "well-known" and should not be used for other traffic modes/types (ie NAT/TPROXY traffic). > > What does specifying two http_port mean? How do I configure my > iptables and dansguardian to use these ports? Currently, DG is > configured with "proxyport = 3128" Do I change that, add to it or what? Since DG is explicitly configured to use Squid as a proxy the traffic between them is in forward-proxy syntax. The NAT rules and config (ie "intercept" mode flag) should only go in the proxy receiving the traffic from the end-user clients. Note that AFAIK, DansGuardan cannot handle HTTPS well. So the traffic routes are: port 3128 -> DG (port?) -> Squid (http_port localhost:3128) port 80 -> Squid (http_port 8080 intercept) port 443-> Squid (https_port Y intercept ...) PS. DG may be able to handle port 80 syntax, I forget right now. In which case the second route would be: port 80 -> DG (8080) -> Squid (http_port locahost:3128) NOTE 1: Since you have port 443 traffic going straight to Squid it cannot beneft from any DG config rules. You may as well redesign the DG rules to work as Squid access controls and drop DG. Which then becomes: port 3128 -> Squid (http_port localhost:3128 ...) port 80 -> Squid (http_port 8080 intercept ...) port 443-> Squid (https_port Y intercept ...) NOTE 2: ssl-bump is not mentioend above since it has no relevance to the type of traffic arriving on the port. It is a separate feature which may be used on any traffic type to decrypt the portion(s) of that traffic which are encrypted, *if any*. It just does not make much sense to intercept port 443 encrypted traffic without decrypting, which is why ssl-bump is usually on https_port lines with either intercept or tproxy mode flag. > > Without ssl_bump my router's NAT rules are > > -A OUTPUT -p tcp -m tcp --dport 80 -m owner --uid-owner squid -j > ACCEPT -A OUTPUT -p tcp -m tcp --dport 3128 -m owner --uid-owner squid > -j ACCEPT -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT > --to-ports 8080 > > In English: > When they are output from a squid process, accept packets that are > destined for ports 80 or 3128, Before other routing , redirect > packets destined for port 80 to port 8080 > > How must I change this when I am using ssl_bump? Given the above squid port "Y" at whatever number you pick for the HTTPS traffic port. Then your rules get this added after the port-80 redirect: -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports Y Amos
