RE: [squid-users] Cannot access google search results and other https sites through squid proxy.

From: Development Team <>
Date: Sat, 7 Jun 2014 11:46:32 -0700

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
I don't yet follow your traffic flow illustration, but I'll work on it :)

-----Original Message-----
From: Amos Jeffries []
Sent: Wednesday, June 04, 2014 1:07 AM
Subject: Re: [squid-users] 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)

 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

 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

 -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports Y

Received on Sat Jun 07 2014 - 18:46:42 MDT

This archive was generated by hypermail 2.2.0 : Sun Jun 08 2014 - 12:00:04 MDT