[ 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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
