[squid-users] original_dst wrong when using intercept

[Amos Jeffries]

On 23/05/18 09:27, monopot wrote:
> I'm trying to setup a Squid proxy to use in one of our AWS accounts.   If I
> put Squid in with a basic http/https filtering setup (no interception) it
> all works great, but the problem is my company wants us to do HTTPS
> interception so I need to use ssl bump.
> 
> Now if I set Squid up following the AWS guide for SSL numping (
> https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/
> <https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/> 
> ) and make the Squid instance have traffic default routed too it, everything
> works perfect.  BUT, we can't route direct to it as we already have NAT
> Gateways we need to keep, so i need to send traffic to it either direct or
> via an ELB and have clients configured to where Squid is.   I thought if I
> just take the same instance which works when routed and direct traffic to
> it, everything would work but no.
> 
> Turns out as soon as I turn on interception such as /http_port 3129
> *intercept*/ traffic drops.   In the access log the ORIGINAL_DST is
> incorrect with the intercept option in use as it shows the local IP of the
> squid proxy.   If I remove intercept it works, shown below.

The ORIGINAL_DST is correct. It is the dst-IP of the TCP packets when
that traffic arrived at your Squid machines NAT system.

That can happen due to any of these reasons:

0) you have explicit/forward-proxy traffic arriving at the NAT intercept
port.

1) you have destination-NAT operating no some machine between Squid and
the client.

2) you have destination-NAT operating somewhere in the network *after*
Squid forwarding that traffic back at the Squid machine.

3) you have DNS interception operating on the clients DNS lookups
telling them that your Squid IP is "the origin" for those domains.

4) you have DNS interception operating on Squid DNS lookups telling
Squid itself is the "the origin" for those domains.



> 
> 1527022455.315    178 10.10.7.36 TCP_MISS/503 3944 GET
> http://www.google.com/ - ORIGINAL_DST/10.10.3.214 text/html   
> *(original_dst is squid local IP, not working)*
> 1527022535.319    170 10.10.7.36 TCP_MISS/200 12194 GET
> http://www.google.com/ - HIER_DIRECT/216.58.196.132 text/html   * (remove
> intercept, original_dst is correct and works)*
> 
> Any ideas why this is and why it works OK if I route traffic direct and
> don't tell the clients specifically to talk to the proxy with
> export_httpproxy etc?

The intercept works okay *because* you did not configure the client(s)
that way.

NAT interception MUST only be done on the Squid machine itself. The
clients traffic MUST be going to somewhere other than your Squid when
NAT intercepts it. ORIGINAL_DST will be that other place - origin or
external proxy.

To send different types of traffic to the proxy requires different
listening ports to receive them. One for each type of traffic.
 "HTTP" can be an of three types of traffic - explicit/forward, reverse,
and origin syntax.
 "HTTPS" can be any of those three inside TLS wrapper, plus a number of
non-HTTP protocols.

Your Squid will need:
 - http_port for explicit/forward (port 3128) traffic, and
 - http_port for NAT intercept traffic (port 80), and
 - https_port for NAT intercept HTTPS (port 443) traffic, and
 - (maybe) an https_port for TLS explicit proxy traffic.

When ssl-bump is involved each of the above ports should have it as a
configured option as well as their mode type (no mode flag for the
explicit proxy ports).

Overall if you are in a position to configure the clients to be aware of
the proxy that is the best setup to use. Interception of any type
imposes a lot of major problems to the traffic handling and should be
avoided if possible. Intercept is a last-resort type of traffic handling
for applications which are not properly HTTP compliant.


> 
> My squid.conf is this (no blocking atm)
> 
> visible_hostname squid

Te above should be a FQDN so your clients can fetch and render error
page contents correctly.

Alex has already mentioned the other major issues with this squid.conf
setup so I shall skip them here.


> 
> #Handling HTTP requests
> http_port 3129 intercept
> http_access allow all
> 
> #Handling HTTPS requests
> https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept
> acl SSL_port port 443
> http_access allow SSL_port
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1 all
> ssl_bump peek step2 all
> ssl_bump splice step3 all
> ssl_bump terminate step2 all
> 
> http_access deny all
> 
> 
> And my IP tables simply has 
> 
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129
> iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3130
> 

see <https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect>

Please add the corresponding mangle table rule(s) to prevent case (1),
(3) and (4); and the POSTROUTING nat table rule(s) to prevents case (2).

Amos