[squid-users] Non intrusive sslbump for whitelisting (asked many times but..)

[Amos Jeffries]

On 08/11/17 12:18, A. Benz wrote:
> Hi all,
> 
> 
> ## Intro
> 
> I read many blogs and emails on this list related to what I'm trying to 
> do, but most go into bumping or do things that are not as simple as I'm 
> trying to achieve.
> 
> I have an extremely slow line, with very high latency in a remote 
> location. About 14 people are sharing this line. Nowadays with all the 
> mobile apps trying to sync and such, the line stalls to unusable all the 
> time.
> 
> I tried doing filters with firewall or dns level, but those are not 
> effective. In the end I figured squid might be my best option.
> 
> ## End intro
> 
> 
> I have squid 3.5.27 running under LEDE (OpenWrt fork), ie its 
> cross-compiled for a MIPS based SoC (mediatek mt7621). I mention this 
> because you will see some options in the config file that won't make 
> sense otherwise.
> 

NP: That should not be making much difference to the squid.conf 
settings. The worst limitations such devices impose are things that 
should be solved by OS settings outside of squid.conf. eg the cache.log 
going to a pipe for remote logging instead of a filename, and 
system-level FD limits.


> It works great, here's what I'm trying to achieve: Allow access only to 
> a pre-defined list of websites (whitelist). http is straightforward, but 
> if the connection is https all I need to know is domain, if its allowed, 
> let it pass, otherwise terminate.
> 
> this setup is working as intended with the config attached below, 
> however the issue I'm facing is that some servers are "loadbalanced", 
> this would give me the forgery error, eg:
> 
> "SECURITY ALERT: Host header forgery detected on...."
> 

The workarounds and gotcha's listed at 
<https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery> are the 
best you can hope for there. The most successful all-round solution is 
to increase EDNS0 capabilities.


> Here's a specific example, there's a corporate domain for webmail 
> access, and some loadbalance config makes use of different IPs, I think 
> this is what triggers the error. My question is, can I just ignore this 
> error somehow and allow the connection? From what I gather this 
> connection is cut by squid before it reaches the client..

Squid default behaviour is to allow the connection only to the same 
IP:port the client was connecting to. If that is not working your 
network configuration is screwed up. Specifically your routing or NAT.

NAT of the dst-IP:port *MUST NOT* happen on any device between the 
client machine and the proxy machine. Squid needs access directly to the 
kernel NAT records of the device doing that NAT operation. So it can 
only happen on the Squid device.
  You must *route* the packets unchanged to the Squid device (possibly 
over a tunnel if necessary).


> 
> Also if there's anything else obviously wrong with my setup please let 
> me know.
> 
> Many thanks.
> 
> 
> Here's my config:
> 
> 
> ### squid.conf begin
> 
> acl localnet src 10.0.0.0/8
> acl localnet src 172.16.0.0/12
> acl localnet src 192.168.0.0/16
> 
> acl ssl_ports port 443
> 
> acl safe_ports port 80
> acl safe_ports port 443
> acl connect method connect

NP: the default above ACL names are case-sensitive and some of them 
involve built-in default values which you are preventing having any 
effect by using custom lower-case ACL names.


> acl http_whitelist dstdomain "/etc/squid/whitelist.txt"
> acl https_whitelist ssl::server_name "/etc/squid/whitelist.txt"
> acl ips_whitelist dst "/etc/squid/ips.txt"
> 
> http_port 3128 intercept
> http_port 3129

Port 3128 is registered for forward-proxy traffic. Ideally you would 
have those lines reversed like so:

  http_port 3128
  http_port 3129 intercept

... with the corresponding NAT change for the intercept port.

Also, to have your SSL-Bump whitelists applied to forward-proxy CONNECT 
traffic you should have ssl-bump settings on that 3128 forward-proxy 
port matching those on the port 3130 line.


> 
> http_access deny !safe_ports
> http_access deny connect !ssl_ports

> http_access allow ssl_ports

Rather than allowing unlimited access to anyone on the Internet to use 
your limited bandwidth outbound connection for access to port 443 you 
should be using the localnet ACL that restricts use of the proxy to 
people on your LAN - those 14 clients you mentioned sharing the line.

[NP: It is not possible in this setup to determine what remote users are 
abusing your proxy. All traffic logs from your firewall etc will show 
Squid as the client, not the remote [ab]user. Squid access.log records 
you are sending to /dev/null is the *only* record of such activities.]


To make your whitelists have any effect replace the above "allow 
ssl_ports" line with a "deny !localnet" line.

If that change causes issues then your whitelists are incorrect / 
incomplete. You then need the (currently discarded) access.log and/or 
cache.log data to solve the issue properly.


> http_access allow http_whitelist
> http_access allow ips_whitelist
> http_access deny all
> 
> https_port 3130 intercept ssl-bump \
>      cert=/etc/squid/myCA.pem \
>      generate-host-certificates=off dynamic_cert_mem_cache_size=4MB
> 
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> 
> ssl_bump peek step1 all
> ssl_bump splice https_whitelist
> ssl_bump splice ips_whitelist
> ssl_bump terminate all
> 

That seems fine. The problem is not part of this _config_. If you are 
having any SSL-Bump issues please try a build of the latest Squid-4. It 
may be related to bugs in Squid-3 SSL-Bump or modern TLS things Squid-3 
cannot cope with - there is a growing list of those.

> 
> cache deny all

In the latest Squid-3 use "store_miss deny all" instead of the above.

> access_log none

The above is fine if you are certain of the squid.conf working 100% 
properly. But since you are debugging issues you may need those 
transaction details.

NP: access.log can be logged to syslog or a TCP pipe by Squid. To 
deliver the log content externally for normal audit purposes instead of 
using space on the device.

> cache_log /dev/null

You *need* the information logged here. By default only the most 
operationally critical errors are recorded.

NP: the cache.log can usually be a Unix-pipe delivering data to a remote 
server if the local machine is constrained.

> cache_store_log stdio:/dev/null

Above line is *actively* harmful. The Squid-3 default is not to waste 
cycles logging *unless* you enter something like the above in 
squid.conf. The above makes Squid allocate device resources to logging 
that data to /dev/null.

> logfile_rotate 0
> 
> logfile_daemon /dev/null

/dev/null is not a valid application filename.

Build your Squid with --disable-logfile-daemon.

> coredump_dir /tmp/squid
> visible_hostname main_Firewall

The *visible* hostname is the domain delivered to clients and denied 
parties in the URLs to fetch error message data and FTP icons from 
Squid. It needs to be a valid FQDN.

Amos