[squid-users] Connection to cache peer failed "SSL Transparent proxy'

Wed Feb 6 02:45:26 UTC 2019

On 6/02/19 5:28 am, Walid A. Shaari wrote:
> Dear Amos,
> 
> 
> Thank you for your time and response. I have changed the configuration
> to the below. I believe the parent proxy is not using SSL/TLS. I do not
> see the Hello error message any longer ( I hope).  I have not used your
> proposed localnet as I just saw your email, at the time being, the ACL
> is quite open as I am still troubleshooting, will tighten it when I am
> comfortable with a final config.
> 
> - for the 'never direct', are you suggesting I use 'never direct deny
> localnet'?

There are two ways to resolve the issue there.

1) The most often we recommend is to _also_ use the same ACL in an
earlier security check like http_access so the DNS lookup happens early
and the data is more reliably available when the fast-type check needs it.

or,

2) To use something that does not require remote lookups. IP address
tests etc.

It depends on what your policies are as to which is the better approach
to take. It is looking a bit like (2) is probably the way to go. With
the switch from dstdomain to server_name type for the ssl_bump
processing this issue may just disappear.

> 
> by the way, my final goal is to enable https traffic through, not really
> intercept it, by trial and error and reading the mailing list, that
> config below is what seems to be working for me right now, can not
> confirm totally as parent proxy is not under my control, nor is the
> appliance, however from the access.log and system message logs, things
> look better than earlier.  what is the best resource to understand the
> peek and splice, any good places other than squid cache main url?
> 

The documentation of what modern Squid SSL-Bump feature does can be
found at <https://wiki.squid-cache.org/Features/SslPeekAndSplice>. It is
community maintained and kept as up to date as we can.

That page links to the relevant squid.conf documentation for the
relevant pieces. The whole TLS situation is a bit volatile so questions
are welcome here if you are unsure about anything in regards to your
specific Squid version, or observe things not matching that text.

> 
> I did get a couple of new errors, have not worked on them, I might have
> some clues.
> 
> 
>   1- squid[192090]: SECURITY ALERT: Host header forgery detected on
> local=52.138.216.83:443
> <http://52.138.216.83:443/> remote=192.168.3.4:1384
> <http://10.8.103.4:1384/> FD 50 flags=33 (local IP does not match any
> domain IP)
> 
>        I believe this is covered in
> https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
> 

Yes.

> 
>    2- temporary disabling (Unauthorized) digest from 192.168.4.22
> 
>         wondering if  I should add 'always_direct deny all'  and '
> nonhierarchical_direct off'?
> 

To encourage use of the peer when it is possible but not optimal. That
"nonhierarchical_direct off" is the way to go.

But "always_direct deny ..." is a soft negative. It just means don't
*force* things to go direct. So they might still go direct to origin or
via a cache_peer as needed.

"never_direct allow ..." is the directive to force things to go to
cache_peer's or fail. Instead of via DIRECT or ORIGINAL_DST server
connections.

If you try to force things you will run up against the lack of
re-CONNECT features in Squid. That is Squid cannot yet generate CONNECT
tunnels through non-TLS peers like you have.

Given that the intercepted HTTPS traffic must leave Squid over secure
connections that effectively means it cannot use the peer as it normally
would and has to send that traffic via ORIGINAL_DST / DIRECT connections
to the HTTPS server. If those are forbidden the transaction has no
choice but to terminate with an error message.

FWIW: Measurement Factory have an experimental branch adding that
re-CONNECT functionality to Squid, if you are okay running alpha quality
code that may be of interest.
 On the other side, I am working with a client on a configuration that
should result in the needed behaviour for the stable releases. That is
just entering testing and depends on whether they are willing for the
details to be published.

> ####   Anonymous access to parent proxy
> 
> #forwarded_for  delete
> 
> #request_header_access Surrogate-Capability deny all
> 

FYI: the bug behind the S-C header problems is now fixed in v4.5
release. Once you upgrade this can be removed.

> 
> dns_v4_first on
> 
> cache_peer  192.168.4.22  parent 9090 0 no-query
> #sslcapath=/etc/pki/ca-trust/source/anchors/  
> 
> acl local-network dstdomain .azcompany.com  #
> tighten after finalizng troubleshooting, maybe replace with localnet
> 
> http_access allow all
> 
> never_direct deny local-network    # revisit not using DNS for resolution
> 
> never_direct allow all    
> 
> http_port 8080 intercept    # should I really use intercept in here? can
> I get away without it
> 
> https_port 8090 intercept ssl-bump generate-host-certificates=on 
> cert=/etc/squid/ssl_certs/bccaz01CA.pem 
> dynamic_cert_mem_cache_size=16MB #connection-auth=off
> 
> http_port 8100    #forward port not used, only for troubleshooting.
> 
> 
> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
> 
> 
> acl step1 at_step SslBump1
> 
> acl azure_sites  dstdom_regex microsoft.com <http://microsoft.com>
> azure.com <http://azure.com> azureedge.net <http://azureedge.net>
> microsoftazurestack.com <http://microsoftazurestack.com>
> trafficmanager.net <http://trafficmanager.net>  wdcp.microsoft.com
> <http://wdcp.microsoft.com> wdcpalt.microsoft.com
> <http://wdcpalt.microsoft.com> updates.microsoft.com
> <http://updates.microsoft.com>
> 
> acl azure_sites2 dstdom_regex download.microsoft.com
> <http://download.microsoft.com> msdl.microsoft.com
> <http://msdl.microsoft.com> crl.microsoft.com <http://crl.microsoft.com>
> secure.aadcdn.microsoftonline-p.com
> <http://secure.aadcdn.microsoftonline-p.com>
> 

FYI: Regex is a slow procedure so when possible should be avoided. Since
all the above are domain names it looks like dstdomain would be better
with these ACL values. Some maybe using the wildcard dstdomain syntax.

 acl azure_sites dstdomain .microsoft.com \
    .azure.com .azureedge.net \
    .microsoftazurestack.com .trafficmanager.net

 acl azure_sites2 dstdomain .microsoft.com \
    secure.aadcdn.microsoftonline-p.com

> ssl_bump peek step1
> 
> ssl_bump splice  azure_sites azure_sites2 #Avoid bumping Microsoft/Azure
> related sites
> 

The way ACLs work in Squid items on a line like "azure_sites
azure_sites2" *both* have to match for the lines action to be used.

So the above line means all those domains except *.microsoft.com will
*not* be spliced here even if a URL domain was available.

> 
> sslproxy_cert_error allow azure_sites azure_sites2     # is there a
> better way to handle these and log them?
> 

For ssl_bump you should prefer the ssl::server_name or
ssl::server_name_regex type ACLs.

All Squid has in the way of URL at that timing is the CONNECT message
from step 1, which is a raw-IP for intercepted traffic. The domain names
in TLS / ssl_bump come from TLS SNI and server X.509 certificate.

The ssl::server_name ACL uses dstdomain-like comparisons, but against
the TLS handshake values instead of the HTTP request message values or
reverse-DNS names.

Amos