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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
