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

[Marcus Kool]

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.

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.-