Hello Eliezer, 2016-06-15 11:45 GMT+03:00 Eliezer Croitoru <eliezer@xxxxxxxxxxxx>: > Hey Michael, > > I am missing couple details about the setup which might affect the way we would be able to understand what is causing the issue and how to resolve it. > There are changes from squid 2.7 to 3.5 and to my opinion these are mandatory to resolve and to not go one step back. Yes, I saw that 3.5 effectively disabled/obsoleted/deactivated various options. I believe I took care in following through those requirements. > What version of SquidGuard 1.4 did you installed? The patched for squid 3.4+ compatibility? I installed a ready to use package from FreeBSD. I presume that is is ok with squid 3.4, according to its dependencies: # pkg query "%do%dv" squidGuard www/squid3.5.19 databases/db55.3.28_3 Other information for squidGuard: # pkg info squidGuard squidGuard-1.4_15 Name : squidGuard Version : 1.4_15 Installed on : Mon May 30 08:24:17 2016 EEST Origin : www/squidguard Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : www Licenses : GPLv2 Maintainer : garga@xxxxxxxxxxx WWW : http://www.squidguard.org/ Comment : Fast redirector for squid Options : DNS_BL : off DOCS : on EXAMPLES : on LDAP : off QUOTE_STRING : off STRIP_NTDOMAIN : off Shared Libs required: libdb-5.3.so.0 Annotations : repo_type : binary repository : FreeBSD Flat size : 2.24MiB > More details about it here: http://bugs.squid-cache.org/show_bug.cgi?id=3978 > Now if it is indeed patched and works as expected it from the 3.4+ computability level of things then lets move on. Checking the bug and if I understand correctly, if my squidGuard was not patched then it wouldn't work. This is not the case. It works ok for http urls, ie blocks fine and the user is correctly redirected to the block page setup for this purpose. It's HTTPS I'm having issues with: according to some talks, if something gets blocked by squidguard, something is miscommunicated (or not communicated at all) with squid. Instead of a block, the users waits endlessly for the page. > Are you using Squid in intercept\transparent\trpoxy mode or is it defined in the browsers directly? > If you are using intercept mode, what have you defined on the FreeBSD pf\ipfw? Squid operates in normal mode. I've configured a 10year old proxy autodiscovery script, which is published through DHCP. All browsers are set to configure everything automatically. > And about the quote from the mailing list: > SquidGuard was written to operate under the url_rewrite interface\protocol and not external_acl. I've lost you here: why do I need squidGuard to operate under external_acl? Can't I leave it running with url_rewrite? > Due to this it has some disadvantages and the advised details are to modify the helper(SquidGuard or another) to operate in another way. > It is possible to use the patched version of SquidGuard under the external_acl interface and use squid options to deny\redirect the request. I saw your other email, but I again have to ask. My own squidguard "seems" to work. What are the merits of doing things with external_acl instead of the way I am doing things right now? > It removes some things from the complexity of the issue. > I have just written an example on how to use use my software SquidBlocker under external_acl and here the adapted example that can be used with a patched SquidGuard: > ## START OF SETTINGS > external_acl_type filter_url ipv4 concurrency=0 ttl=3 %URI %SRC/- %LOGIN %METHOD /usr/local/bin/squidGuard url_rewrite_children > acl filter_url_acl external filter_url > deny_info http://ngtech.co.il/block_page/?url=%u&domain=%H filter_url_acl > #or > # deny_info 302:http://ngtech.co.il/block_page/?url=%u&domain=%H filter_url_acl > http_access deny !filter_url_acl > http_access allow localnet filter_url_acl > ## END OF SETTINGS > > I have not tested this request format but if it doesn't work this way then a little cosmetics will make it work. > > When more information will be available we can try to see where the issue is from. > > Eliezer > > ---- > Eliezer Croitoru > Linux System Administrator > Mobile: +972-5-28704261 > Email: eliezer@xxxxxxxxxxxx > > > -----Original Message----- > From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of reqman > Sent: Wednesday, June 15, 2016 10:22 AM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: HTTPS issues with squidguard after upgrading from squid 2.7 to 3.5 > > Hello all, > > I have been running squid 2.7.X alongside squidguard 1.4 on a FreeBSD 8.x box for years. > Started out some 10 years ago, with a much older squid/squidguard/FreeBSD combination. > > Having to upgrade to FreeBSD 10.3, I examined my option regarding squid. > 3.5.19 was available which I assumed would behave the same as 2.7, regarding compatibility. > Squidguard 1.4 was also installed. > > - Squid was configured to behave along the lines of what I had on 2.7. > - For squidguard I used the exact same blocklists and configurations. > Note that I do not employ an URL rewriting in squidguard, only redirection. > - no SSL-bump or other SSL interception takes place > - the squidguard-related lines on squid are the following: > > url_rewrite_program /usr/local/bin/squidGuard url_rewrite_children 8 startup=4 idle=4 concurrency=0 > url_rewrite_access allow all > > - In squidGuard.conf, the typical redirect section is like: > > default { > pass local-ok !block1 !block2 !blockN all > redirect > 301:http://localsite/block.htm?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u > } > > I am now experiencing problems that I did not have. Specifically, access to certain but *not* all HTTPS sites seems to timeout. > Furthermore, I see entries similar to the following in cache.log: > > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3446 FD 591 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3448 FD 592 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3452 FD 594 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3456 FD 596 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3454 FD 595 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3458 FD 597 flags=1 > 2016/06/15 09:27:59 kid1| abandoning local=192.168.0.1:3128 > remote=192.168.2.239:3462 FD 599 flags=1 > > Searching around, the closest I have come to an answer is the > following: http://www.squid-cache.org/mail-archive/squid-users/201211/0165.html > I am not sure though whether I am plagued by the same issue, considering that the thread refers to a squid version dated 4 years ago. And I definitely do not understand what the is meant by the poster's proposal: > > "If you can't alter the re-writer to perform redirection you can work around that by using: > > acl foo ... some test to match the re-written URL ... > deny_info 302:%s foo > adapted_http_access deny foo " > > Can someone help resolve this? > Is the 2.7 series supported at all? > As is if everything fails, I'll have to go back to it if there's some support. > > BR, > > > Michael.- > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
