[squid-users] Connection to cache peer failed "SSL Transparent proxy'
Walid A. Shaari
walid.shaari at linux.com
Tue Feb 5 16:28:27 UTC 2019
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'?
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?
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 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
2- temporary disabling (Unauthorized) digest from 192.168.4.22
wondering if I should add 'always_direct deny all' and '
nonhierarchical_direct off'?
#### Anonymous access to parent proxy
#forwarded_for delete
#request_header_access Surrogate-Capability deny all
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 azure.com azureedge.net
microsoftazurestack.com trafficmanager.net wdcp.microsoft.com
wdcpalt.microsoft.com updates.microsoft.com
acl azure_sites2 dstdom_regex download.microsoft.com msdl.microsoft.com
crl.microsoft.com secure.aadcdn.microsoftonline-p.com
ssl_bump peek step1
ssl_bump splice azure_sites azure_sites2 #Avoid bumping Microsoft/Azure
related sites
sslproxy_cert_error allow azure_sites azure_sites2 # is there a better
way to handle these and log them?
debug_options ALL,9
On Tue, 5 Feb 2019 at 09:25, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> [ Rules horribly mangled by sending a web page to a plain-text mailing
> list. I have fixed some where I replied, but not all. ]
>
>
> On 5/02/19 4:07 am, Walid A. Shaari wrote:
> > Hello,
> >
> > I have a squid proxy, trying to configure it to enforce traffic from a
> > private cloud appliance (Azure Stack) to go over to the corporate proxy.
> > traffic is mostly https, I see the below errors, note
> > that ParentProxy-22 is the parent proxy listening on port 9090.
>
>
>
> > also,
> > why in the access logs I have some entries not going to parent proxy
> > (e.g. 1549282865.527 13 192.168.3.10 NONE/200 0
> > CONNECT 52.138.216.83:443 <http://52.138.216.83:443/> - HIER_NONE/- -)
> >
>
> Some transactions do not need server contact. The above "CONNECT" with
> raw-IP:port, "NONE" status type, "NONE" peer type and 0 byte size is
> what gets logged for the SSL-Bump step-1 interaction when only a TCP SYN
> packet has actually happened.
>
> NP: Each step of SSL-Bump process has a separate log entry with
> incrementally more data up to the one with a 'final' result which
> instead logs the decrypted transactions or the error.
>
>
> > ### error logs ###Feb 4 15:26:38 azproxy squid[192272]: TCP connection
> > to ParentProxy-22/9090 failed
> > Feb 4 15:26:38 azproxy squid[192272]: Error parsing SSL Server Hello
> > Message on FD 20
> > Feb 4 15:26:38 azproxy squid[192272]: ERROR: negotiating TLS on FD 20:
> > error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> > (1/-1/0)
>
> The OpenSSL library on your proxy machine does not understand the
> protocol that it is receiving in the supposedly TLS / HTTPS traffic.
>
> Usually seeing this on peer connections means the peer is *not* a TLS
> explicit proxy, nor HTTPS / TLS origin server. Such things respond in
> their actual protocol with an error -> OpenSSL displays that message.
>
>
> ...>
> > cache_peer ParentProxy-22 parent 9090 0 no-query
> > sslcapath=/etc/pki/ca-trust/source/anchors/
>
> Two things of note:
>
> 1) as above, does this peer *actually* support TLS connections on its
> port 9090?
> Native TLS connections, not HTTP Upgrade or anything like that.
>
> 2) That sslcapath= is providing an entire set of CA's. Any given server
> typically has one certificate, signed by one CA. So it is rare that you
> would need an entire set of CA's to be trusted by this proxy.
>
> For better security you should be able to load the specific CA that peer
> uses with sslcafile= instead of the whole path.
>
>
> > acl local-network dstdomain .azcompany.com
> > acl everything src 10.0.0.0/8
> > http_access allow everything
>
>
> These are very deceptive.
>
> * "everything" is actually a small sub-set of 'things'.
>
> * "local-network" is not necessarily local. Any IP address with
> reverse-DNS configured to claim its name is within *.azcompany.com will
> match this ACL regardless of where in the world it actually is.
>
>
> The default squid.conf defines an ACL "localnet" (Local Network) for the
> permitted clients subnet.
>
> The ACL called "all" is provided to match every transaction with a
> client IP.
>
>
> > never_direct deny local-network
>
>
> Fine, but why are you waiting until a place (never_direct) where Squid
> is unable to wait for results of reverse-DNS lookup?
> That will result in unpredictable non-match occuring whenever DNS TTL
> is encountered.
>
>
> > never_direct allow all
> > http_port 8080 intercept
> > https_port 8090 intercept ssl-bump generate-host-certificates=on
> > cert=/etc/squid/ssl_certs/azproxyCA.pem dynamic_cert_mem_cache_size=16MB
> > #connection-auth=off
> > http_port 8100 #forward port not used.
> >
> > sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> > /var/spool/squid/ssl_db -M 4MB
> > acl step1 at_step SslBump1
> > ssl_bump peek step1
> > ssl_bump bump all
>
> > tls_outgoing_options /etc/pki/ca-trust/source/anchors/ca.crt
>
> Squid should be telling you on startup that there is no valid option
> named "/etc/pki/ca-trust/source/anchors/ca.crt"
>
> tls_outgoing_options directive takes a set of k=v pairs setting the
> options just like http(s)_port and cache_peer.
>
>
>
> HTH
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190205/8b45d05c/attachment-0001.html>
More information about the squid-users
mailing list