23.7.8 - Squid 6.4 unusable due to repeated crashes

[zan]

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.

[franco]

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

[doktornotor]

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.

[schnipp]

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.

[newsense]

schnipp is right, controlling egress traffic is crucial for any environment big or small and should default to closed for everyone

[franco]

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.

[schnipp]

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.