# Squid Caching Proxy Security Audit: 55 Vulnerabilities, 35 0days **URL:** \ **Category:** Security\ **Created:** [11 October 2023 10:53 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440 "2023-10-11T10:53:04Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![tphz](https://community.ipfire.org/user_avatar/community.ipfire.org/tphz/32/16551_2.png) [@tphz](https://community.ipfire.org/u/tphz)\ **Post date:** [11 October 2023 10:53 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/1 "2023-10-11T10:53:04Z")
Just for information > **[oss-sec: Squid Caching Proxy Security Audit: 55 Vulnerabilities, 35 0days.](https://seclists.org/oss-sec/2023/q4/82)** ---
**Author:** ![pike\_it](https://community.ipfire.org/user_avatar/community.ipfire.org/pike_it/32/16425_2.png) [@pike\_it](https://community.ipfire.org/u/pike_it)\ **Post date:** [11 October 2023 13:14 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/2 "2023-10-11T13:14:41Z")
Unfortunately squid is a old piece of software written for older times with specific goals. The rise of SSL/TLS it’s making that almost unsable (unless peek&splice approach). ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 October 2023 13:58 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/3 "2023-10-11T13:58:04Z")
All the ones with CVE numbers had fixes applied to squid-4.15 or 5.06 Around the same time as the CVE’s were raised IPFire updated to 4.15 Currently IPFire is on 6.2 Some entries can be found in the squid bugzilla and are resolved (basically the CVE entries) or marked as Unconfirmed still. Others I could not find in the squid bugzilla at all. Searched by reporter name. I think we will need to see what the squid developers say about this. ---
**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\ **Post date:** [11 October 2023 14:16 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/4 "2023-10-11T14:16:50Z")
> [@bonnietwin](#): > > I think we will need to see what the squid developers say about this. two years of silence is a bit worrying though, at least assuming what is written in that message is accurate. ---
**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\ **Post date:** [11 October 2023 14:21 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/5 "2023-10-11T14:21:06Z")
> [@pike\_it](#): > > Unfortunately squid is a old piece of software written for older times with specific goals. The rise of SSL/TLS it’s making that almost unsable (unless peek&splice approach). why is that? I assume I do not understand the issue well enough, but I could not help avoid forming the opinion that a proxy probably should not terminate a tunnel but just pass the “literal” bits between the two parties. This is based on the assumption that no third party, without exceptions, has any legittimate reason to read the encrypted communication I establish with my counterpart. This is also an argument not just for privacy, but to legally protect a business enterprise offering a cache service for its clients. This is off topic, but I will add this consideration, premature tunnel termination is the attack vector the authoritarian governments are using to legislate against end-to-end encryption. Our phones will be scanning our images, emails, chat etc. before encryption or after they get decrypted. These people would love to have proxy providers do the same, nullifying the entire TLS/SSL technology. We must resist this push. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [11 October 2023 14:41 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/6 "2023-10-11T14:41:38Z")
> [@cfusco](#): > > two years of silence is a bit worrying though, at least assuming what is written in that message is accurate. That is what I am not sure about. Looking through the users and dev mailing lists on squid I found that users name three timers and none of those conversations were related to the issues in the report. All the CVE’s were dealt with, so the question is if the squid developers believed those other items were something that needed to be fixed or not but I can’t find much on those and as I said also no reports in the squid bugzilla, although that could also be my poor search skills in it. > [@cfusco](#): > > why is that? I assume I do not understand the issue well enough, but I could not help avoid forming the opinion that a proxy probably should not terminate a tunnel but just pass the “literal” bits between the two parties. That is exactly what it does for IPFire, but therefore there is nothing to cache for the proxy. All squid could do is store the encrypted traffic content in its cache but it wouldn’t know which new traffic requests were covering the same information as the new traffic would also be encrypted. ---
**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\ **Post date:** [11 October 2023 14:46 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/7 "2023-10-11T14:46:48Z")
> [@bonnietwin](#): > > Looking through the users and dev mailing lists on squid I found that users name three timers and none of those conversations were related to the issues in the report. probably the conversation was not public. > [@bonnietwin](#): > > but therefore there is nothing to cache for the proxy I didn’t connect the dots. Now I better understand the issue. Thank you. ---
**Author:** ![hvacguy](https://community.ipfire.org/user_avatar/community.ipfire.org/hvacguy/32/8576_2.png) [@hvacguy](https://community.ipfire.org/u/hvacguy)\ **Post date:** [11 October 2023 19:52 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/8 "2023-10-11T19:52:15Z")
> [@pike\_it](#): > > Unfortunately squid is a old piece of software written for older times with specific goals. The rise of SSL/TLS it’s making that almost unsable (unless peek&splice approach). This is exactly why HTTPS is fundamentally broken. when every ISP and Government can sit there. ---
**Author:** ![pike\_it](https://community.ipfire.org/user_avatar/community.ipfire.org/pike_it/32/16425_2.png) [@pike\_it](https://community.ipfire.org/u/pike_it)\ **Post date:** [12 October 2023 09:11 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/9 "2023-10-12T09:11:28Z")
We could have a conversation about TLS (which transforms HTTP to HTTP **S** ) is or is not fundamentally broken, but this is not the topic. Also, is there an interesting conversation about why an ISP and a Goverment should (or should not) sit on some things. But IMVHO this is not the community for. ---
**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\ **Post date:** [12 October 2023 09:29 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/10 "2023-10-12T09:29:09Z")
> [@pike\_it](#): > > We could have a conversation about TLS (which transforms HTTP to HTTP **S** ) is or is not fundamentally broken, but this is not the topic. I would like to have that conversation. Maybe a dedicated thread? ---
**Author:** ![pike\_it](https://community.ipfire.org/user_avatar/community.ipfire.org/pike_it/32/16425_2.png) [@pike\_it](https://community.ipfire.org/u/pike_it)\ **Post date:** [12 October 2023 13:27 UTC](https://community.ipfire.org/t/squid-caching-proxy-security-audit-55-vulnerabilities-35-0days/10440/11 "2023-10-12T13:27:30Z")
Anyway, keeping IT the topic. Am I wrong or the post has be completely ignored? More links related. > **[Squid Caching Proxy Security Audit: 55 vulnerabilities and 35 0days](https://megamansec.github.io/Squid-Security-Audit/)** > > A detailed repository of vulnerabilities that I discovered in The Squid Caching Proxy. > **[55 Vulnerabilities in Squid Caching Proxy and 35 0days](https://joshua.hu/squid-security-audit-35-0days-45-exploits)** > > In 2021, I performed a security audit of The Squid Caching Proxy. Squid is by far the most well known open-source forwarding HTTP proxy, and is used in many contexts, like corporations that want to filter or cache content, companies that claim to... consider that the _second_ link reports also “availability” for rent skills and time about the dude.