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

[Amos Jeffries]

[ 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