OPNsense Forum
English Forums => 23.7 Legacy Series => Topic started by: xavx on November 10, 2023, 10:38:02 am
-
Squid6.4 keeps crashing and dumping core. This wasn't happening with the previous version.
Always the same fatal error in cache log :
kid1| FATAL: assertion failed: stmem.cc:98: "lowestOffset () <= target_offset"
This isn't an isolated occurrence - see https://www.mail-archive.com/squid-users@lists.squid-cache.org/msg25028.html. Crashes were apparently not happening in 6.3
-
Yeah, people asked for Squid to be updated due to security updates. 6.5 is out but FreeBSD ports only has 6.4 and it's not 100% clear 6.5 will fix it. Also see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274825
-
I guess almost constant crashing is a good way to prevent security risks.
More seriously, I think it would have been better to keep the previous version or go for 6.3 and highlight the risks rather than providing an updated version that doesn't work and will trigger people to ask for help.
-
Yeah, hindsight is always 20/20, but I'm not going to touch subject again before Monday.
Cheers,
Franco
-
FYI: Same error here.
-
Same error here.
Is there any workarround for this ?
- Downgrade manually ?
- other webproxy
- ...
My users are complaining, they do not have direct internet access.
Regards
Skar
-
FreeBSD ports just updated to 6.5 so here is a test package:
# opnsense-revert -z squid
Cheers,
Franco
-
Thanks, works fine for me.
-
ok, hotfixed it
-
6.5 seems fine. No crash so far.
Please improve the QA. Are updates not pushed first to development branch and test gear before deployment to production branch ? This issue and the others would have been quickly spotted. Guess it's better to wait a week before deploying updates
-
Today I updated the version and I had the same problem, I updated to version 6.5, the problem was corrected, it is working fine.
Thank you so much
FreeBSD ports just updated to 6.5 so here is a test package:
# opnsense-revert -z squid
Cheers,
Franco
-
Please improve the QA. Are updates not pushed first to development branch and test gear before deployment to production branch ? This issue and the others would have been quickly spotted. Guess it's better to wait a week before deploying updates
You want us to spot an issue that neither FreeBSD ports nor Squid itself found in 6.4? I'm not sure how that works, but I can say for a free software with a BSD license a hotfix within 24 hours is a responsible procedure.
To be frank I did not see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274825 before 23.7.8 was out. Then people actually started reporting the issue with Squid. I've spent much time migrating and testing 5.9 to 6.4 this week to make sure it builds and runs and the language pack is still in place.
The safest bet would have been to keep Squid at 5.9 for the whole 23.7.x progression, but the security issues made this more or less an impossible choice: migrate to next stable version and receive regression complaints or not update it at all and receive missing security update complains. I'd rather choose the regression complaints also because forward is the only viable direction eventually.
Cheers,
Franco
-
So, frankly - how many of those endless exploits and 0days (https://joshua.hu/squid-security-audit-35-0days-45-exploits) have been fixed in upstream and/or in FreeBSD ports? I'd say the future is not exactly bright for Squid.
The Squid Team have been helpful and supportive during the process of reporting these issues. However, they are effectively understaffed, and simply do not have the resources to fix the discovered issues.
For everyone here, instead of complaining about QA, I'd seriously reconsider your use case for Squid proxy.
-
So, frankly - how many of those endless exploits and 0days (https://joshua.hu/squid-security-audit-35-0days-45-exploits) have been fixed in upstream and/or in FreeBSD ports? I'd say the future is not exactly bright for Squid.
The Squid Team have been helpful and supportive during the process of reporting these issues. However, they are effectively understaffed, and simply do not have the resources to fix the discovered issues.
For everyone here, instead of complaining about QA, I'd seriously reconsider your use case for Squid proxy.
Hi,
i can only agree 100%!
cheers
till
-
AFAIK "The other side" will pull squid support from next release(s) , due to the increasing security issues.
-
Just curious is Squid still relevant today? Given most traffic are HTTPS it seems less useful for caching, unless we are doing MITM SSL inspection - it was PITA to make it work reliably the last time I tried.
For content filtering it can be done with DNS based filtering like Adguard, pihole etc.
-
I tend to agree to the last few messages. We should probably move squid to plugins and lower to support tier 2.
I don't think complete removal is a good approach as long as the software keeps releasing new versions, but relevance is indeed completely different than it was 10 years ago (when the writing was on the wall as well).
Cheers,
Franco
-
Just curious is Squid still relevant today? Given most traffic are HTTPS it seems less useful for caching, unless we are doing MITM SSL inspection - it was PITA to make it work reliably the last time I tried.
For content filtering it can be done with DNS based filtering like Adguard, pihole etc.
I spent probably couple hundreds of hours fixing Squid on the other project many years back. Even then, what vast majority of people wanted was MITM, particularly the super-easy mode allowing (limited) MITM without custom certificates installed on clients (never found the exact GUI equivalent in OPNsense).
For reverse proxies, HAproxy or nginx are much better option.
Caching - well, meh unless you live in the middle of nowhere with a horrible single ISP providing dialup speeds.
Content filtering - there were 2 category based content filtering blacklists (UT, Shalla) - which are both abandoned. Plus, the Squidguard package code was a piece of mess I refused to touch for mental sanity reasons.
Moving this from core into a plugin with proper warnings about upstream state and security implications sounds like a good idea.
-
Just curious is Squid still relevant today?
Of course it's relevant. A forward proxy like Squid to filter content is a good tool, and DNS filtering is not a replacement for it. DNS filtering can only prevent hostname resolution, not access to any endpoints. However, if the client resolves hostnames in another way (DoH, DoT), there is no way to prevent access to requested resources. In principle, the firewall can prevent the use of DoT in most cases by blocking its standard port - there will probably also be DoT providers with port TCP/443. Filtering DoH network traffic can be very difficult.
A forward proxy controls access to an endpoint's resources. MiTM is not required for this if filtering is based on the hostname or IP address of the endpoint itself.
With enough effort, the filtering can be overcome despite the techniques mentioned above. But in my eyes, overcoming a filter proxy is more difficult compared to DNS filtering. A good approach is to combine the techniques mentioned sensibly.
-
schnipp is right, controlling egress traffic is crucial for any environment big or small and should default to closed for everyone
-
This is about squid, not content filtering in general. I think the way the proxy works was good until DPI started to appear on the scene and since then TLS and HTTP have also made advancements that make it harder for the traditional proxy to cope properly. Content filtering via DNS is much more popular nowadays than it used to with all of its problems and loopholes (DNS itself also evolved).
And companies heavily rely on endpoint security software to protect the infrastructure now. Getting people off of Facebook/Meta to do work is not so relevant in 2023 either. ;)
-
I think forward proxies have their place in terms of filtering despite DPI. I'm not a fan of breaking TLS connections for a variety of reasons. A forward proxy can make its decision depending on the requested host (or IP address). This requires neither DPI, TLS inspection nor client-side DNS resolution.