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

[Walid A. Shaari]

On Wed, 6 Feb 2019 at 05:53, Amos Jeffries <squid3 at treenet.co.nz> wrote:

>
> 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.
>
>
Thank you, will try it tomorow.

>
> >
> > 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.
>
> ..... ..... ......
> 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.
>

I am ok if it resolves my issues and does not introduce new bugs, I have
some deadlines that I need to meet or otherwise drop all of this.

>
>
>  > ####   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.
>

I am on v4.5

>
>  >
> > 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


Great, thanks, will use that definitely.

>
>
>
> > 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.
>

Sorry, I did not get that, is it because microsoft.com is duplicated by
mistake twice on both lines?

Thank you Amos, you were great help.

Walid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190206/4e3934ef/attachment-0001.html>