[squid-users] HTTPS issues with squidguard after upgrading from squid 2.7 to 3.5

[Pavel Timofeev]

2016-06-15 14:24 GMT+03:00 reqman <reqman at freemail.gr>:
> 2016-06-15 13:48 GMT+03:00 Marcus Kool <marcus.kool at urlfilterdb.com>:
>>
>>
>> On 06/15/2016 04:22 AM, reqman wrote:
>>>
>>> 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.
>>
>>
>> A great decision to go to Squid 3.5.19, but it is a large leap so
>> you might expect some compatibility issues.
>>
>> Squidguard has no support nor maintenance for many years and the patch
>> for squidguard to become compatible with squid 3.4+ was written by a Squid
>> developer.
>> Hence I recommend to install ufdbGuard, which is a fork of squidGuard and
>> does have support and updates.  ufdbGuard is also 3x faster and uses less
>> memory, so plenty of reasons to say goodbye to squidGuard.
>
> I have been using squidGuard for 10+ years. Not the best one could
> have, but I am accustomed to its use and idiosyncrasies. Furthermore,
> it is package well supported on FreeBSD.
>
> You are mentioning ufdbGuard. Are its lists free for government use?
> If not, then I can not use it, since we have very strict purchasing
> requirements, even if it costs $1. And of course, I would have to go
> through evaluation, the usual learning curve etc.
>
> Don't get me wrong here, I'm not saying no. I'm just saying that even
> though it seems to be easy to say "yes", reality is much different.
>
> M.-
>

Hi!

I've made a freebsd port for ufdbGuard.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212044
I'd appreciate any kind of feedback.

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