On 9/10/19 8:36 pm, torson wrote: > @Amos thank you for your detailed reply. It took me a while to get back to > this task, sorry. > I did some changes, added your suggestions, tested some more and here are my > results using Squid 4.8 with a couple of questions: > > A short summary of my setup: Squid that does only intercept for all servers > in the same network. There's Dnsmasq set up on the same server and is used > by Squid and all other servers. > > ### 1. https certificate check > I've managed to make it work with "ssl_bump peek all" but it started working > only after I've switched the order of splice and peek: > --- > ssl_bump splice allowed_https_sites > ssl_bump peek all > ssl_bump terminate all > --- With an intercept proxy this makes the proxy do: step 1) peek (allowed_https_sites does not match), then step 2) splice if allowed_https_sites matched, else peek step 3) splice if allowed_https_sites matched, else terminate > > Though now I don't get "terminate" entries in the logfile for blocked > requests for most domains I'm testing with, instead those are now "peek" > entries. > Do you actually understand why? The earlier setups you were either splicing only at step 1 OR only at step 2. This new setup can splice at whichever step supplies a whitelisted domain name. So now clients which lie are allowed to splice, AND clients which do not supply SNI but go to an okay server are allowed to splice. NP: clients which lie may not be as bad as it seems. With splice the server gets the lie and can reject the request if it is legitimate. For there to be a security problem the client and server need to collude. ... > > So there seems to be variations on how Squid is handling traffic for various > sites. Of course, you put data-dependent conditions (allowed_https_sites ACL) on what handling can be performed. Thus making the proxy behaviour conditional on what Hello data the remote TLS agents are supplying. As clients and servers differ so will the resulting proxy behaviour. > I lean more towards having increased security than consistent logging, seems > like "peek" effectively means "terminate" in this case, so I'll just count > that together for alerting. On the contrary, since this is an interception proxy peek will always preceed both splice and terminate. If the logging is working correctly you will see the peek's AND the splice's AND any terminate's. > > Do you have some suggestion to make this work better or is this just the > best I can squeeze out of Squid at this time? > AFAIK this is the best available in Squid-4. The latest Squid-5 may be slightly better, it has a number of quality-of-life feature additions for TLS related things. > ### 2. false host-forgery blocking due to stale DNS record > ... > > Do you have some suggestions regarding this? Am I thinking in the right > direction? AFAIK those directions are reasonable for Squid today. We are still waiting on someone having the time/resources to contribute a refactor to Squid DNS that further reduces these false-positives. I have a plan, but no time to implement it. Factory people have laid a lot of the groundwork in Squid-5 but we are not completely there yet. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
