[squid-users] [squid-announce] Squid 4.13 is available

[Amos Jeffries]

The Squid HTTP Proxy team is very pleased to announce the availability
of the Squid-4.13 release!


This release is a security release resolving several issues found in
the prior Squid releases.


The major changes to be aware of:

 * SQUID-2020:8 HTTP(S) Request Splitting
   (CVE-2020-15811)

This problem is serious because it allows any client, including
browser scripts, to bypass local security and poison the browser
cache and any downstream caches with content from an arbitrary
source.

See the advisory for patches:
 


 * SQUID-2020:9 Denial of Service processing Cache Digest Response
   (CVE pending allocation)

This problem allows a trusted peer to deliver to perform Denial
of Service by consuming all available CPU cycles on the machine
running Squid when handling a crafted Cache Digest response
message.

This attack is limited to Squid using cache_peer with cache
digests feature.

See the advisory for patches:
 


 * SQUID-2020:10 HTTP(S) Request Smuggling
   (CVE-2020-15810)

This problem is serious because it allows any client, including
browser scripts, to bypass local security and poison the proxy
cache and any downstream caches with content from an arbitrary
source.


See the advisory for patches:
 


 * Bug 5051: Some collapsed revalidation responses never expire

This bug appears as a 4xx or 5xx status response becoming the only
response delivered by Squid to a URL when Collapsed Forwarding
feature is used.

It primarily affects Squid which are caching the 4xx/5xx status
object since Bug 5030 fix in Squid-4.11. But may have been
occurring for short times on any proxy with Collapsed Forwarding.



 * SSL-Bump: Support parsing GREASEd (and future) TLS handshakes

Chrome Browser intentionally sends random garbage values in the
TLS handshake to force TLS implementations to cope with future TLS
extensions cleanly. The changes in Squid-4.12 to disable TLS/1.3
caused our parser to be extra strict and reject this TLS garbage.

This release adds explicit support for Chrome, or any other TLS
agent performing these "GREASE" behaviours.


 * Honor on_unsupported_protocol for intercepted https_port

This behaviour was one of the intended use-cases for unsupported
protocol handling, but somehow was not enabled earlier.

Squid should now be able to perform the on_unsupported_protocol
selected action for any traffic handled by SSL-Bump.


  All users of Squid are urged to upgrade as soon as possible.


See the ChangeLog for the full list of changes in this and earlier
releases.

Please refer to the release notes at
http://www.squid-cache.org/Versions/v4/RELEASENOTES.html
when you are ready to make the switch to Squid-4

This new release can be downloaded from our HTTP or FTP servers

  http://www.squid-cache.org/Versions/v4/
  ftp://ftp.squid-cache.org/pub/squid/
  ftp://ftp.squid-cache.org/pub/archive/4/

or the mirrors. For a list of mirror sites see

  http://www.squid-cache.org/Download/http-mirrors.html
  http://www.squid-cache.org/Download/mirrors.html

If you encounter any issues with this release please file a bug report.
  http://bugs.squid-cache.org/


Amos Jeffries
___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] [squid-announce] Squid 5.0.4 beta is available

[Amos Jeffries]

The Squid HTTP Proxy team is very pleased to announce the availability
of the Squid-5.0.4 beta release!


This release is a security and feature update release resolving
several issues found in the prior Squid releases.


The major changes to be aware of:

 * SQUID-2020:8 HTTP(S) Request Splitting
   (CVE-2020-15811)

This problem is serious because it allows any client, including
browser scripts, to bypass local security and poison the browser
cache and any downstream caches with content from an arbitrary
source.

See the advisory for patches:
 


 * SQUID-2020:9 Denial of Service processing Cache Digest Response
   (CVE pending allocation)

This problem allows a trusted peer to deliver to perform Denial
of Service by consuming all available CPU cycles on the machine
running Squid when handling a crafted Cache Digest response
message.

This attack is limited to Squid using cache_peer with cache
digests feature.

See the advisory for patches:
 


 * SQUID-2020:10 HTTP(S) Request Smuggling
   (CVE-2020-15810)

This problem is serious because it allows any client, including
browser scripts, to bypass local security and poison the proxy
cache and any downstream caches with content from an arbitrary
source.


See the advisory for patches:
 


 * Add http_port sslflags=CONDITIONAL_AUTH

This release extends the client certificate features to allow
optional certificate authentication.

The existing DELAYED_AUTH flag would delay the certificate request,
then reject all clients who cannot present a valid certificate
on request.

With CONDITIONAL_AUTH Squid will just request and validate SSL
client certificates. Any rejection or use of those certificates
is left to other configuration settings.


 * Improved CONNECT tunnel handling

This release contains several small but important changes to how
Squid handles CONNECT tunnels opened with servers. Particularly
in cases of server TCP connection failure and switching between
upstream peers.

A lot of annoying on_unsupported_protocol and HTTPS forwarding
behaviour issues with previous releases should be resolved by
these changes.



  All users of Squid-5 are urged to upgrade as soon as possible.

  All users of Squid-4 and older are encouraged to plan for upgrade.


See the ChangeLog for the full list of changes in this and earlier
releases.

Please refer to the release notes at
http://www.squid-cache.org/Versions/v5/RELEASENOTES.html
when you are ready to make the switch to Squid-5

This new release can be downloaded from our HTTP or FTP servers

  http://www.squid-cache.org/Versions/v5/
  ftp://ftp.squid-cache.org/pub/squid/
  ftp://ftp.squid-cache.org/pub/archive/5/

or the mirrors. For a list of mirror sites see

  http://www.squid-cache.org/Download/http-mirrors.html
  http://www.squid-cache.org/Download/mirrors.html

If you encounter any issues with this release please file a bug report.
  http://bugs.squid-cache.org/


Amos Jeffries
___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] [squid-announce] [ADVISORY] SQUID-2020:8 HTTP(S) Request Splitting

[Amos Jeffries]

__

Squid Proxy Cache Security Update Advisory SQUID-2020:8
__

Advisory ID:   | SQUID-2020:8
Date:  | August 23, 2020
Summary:   | HTTP(S) Request Splitting.
Affected versions: | Squid 2.7 -> 2.7.STABLE9
   | Squid 3.x -> 3.5.28
   | Squid 4.x -> 4.12
   | Squid 5.x -> 5.0.3
Fixed in version:  | Squid 4.13, 5.0.4
__

  
__

Problem Description:

 Due to incorrect data validation Squid is vulnerable to HTTP
 Request Splitting attacks against HTTP and HTTPS traffic. This
 leads to cache poisoning.

__

Severity:

 This problem is serious because it allows any client, including
 browser scripts, to bypass local security and poison the browser
 cache and any downstream caches with content from an arbitrary
 source.

CVSS Score of 9.3


__

Updated Packages:

This bug is fixed by Squid versions 4.13 and 5.0.4.

 In addition, patches addressing this problem for the stable
 releases can be found in our patch archives:

Squid 4:
 

 If you are using a prepackaged version of Squid then please refer
 to the package vendor for availability information on updated
 packages.

__

Determining if your version is vulnerable:

 All Squid configured with "relaxed_header_parser off" are not vulnerable.

 All Squid-3.x up to and including 3.5.28 with
 relaxed_header_parser configured to "on" or "warn" are
 vulnerable.

 All Squid-3.x up to and including 3.5.28 without
 relaxed_header_parser configured are vulnerable.

 All Squid-4.x up to and including 4.12 with relaxed_header_parser
 configured to "on" or "warn" are vulnerable.

 All Squid-4.x up to and including 4.12 without
 relaxed_header_parser configured are vulnerable.

 All Squid-5.x up to and including 5.0.3 with
 relaxed_header_parser configured to "on" or "warn" are
 vulnerable.

 All Squid-5.x up to and including 5.0.3 without
 relaxed_header_parser configured are vulnerable.

__

Workaround:

 Disable the relaxed HTTP parser in squid.conf:

relaxed_header_parser off

 Note, traffic which does not correctly obey HTTP specifications
 will be rejected instead of converted to standards compliance.

__

Contact details for the Squid project:

 For installation / upgrade support on binary packaged versions
 of Squid: Your first point of contact should be your binary
 package vendor.

 If you install and build Squid from the original Squid sources
 then the  mailing list is your
 primary support point. For subscription details see
 .

 For reporting of non-security bugs in the latest STABLE release
 the squid bugzilla database should be used
 .

 For reporting of security sensitive bugs send an email to the
  mailing list. It's a closed
 list (though anyone can post) and security related bug reports
 are treated in confidence until the impact has been established.

__

Credits:

 This vulnerability was discovered by Regis Leroy (regilero
 from Makina Corpus).

 Fixed by Amos Jeffries of Treehouse Networks Ltd.

__

Revision history:

 2019-07-24 11:52:51 UTC Initial Report
 2020-01-09 22:07:44 UTC Additional vectors discovered
__
END
___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] [squid-announce] [ADVISORY] SQUID-2020:9 Denial of Service processing Cache Digest Response

[Amos Jeffries]

__

Squid Proxy Cache Security Update Advisory SQUID-2020:9
__

Advisory ID:   | SQUID-2020:9
Date:  | August 23, 2020
Summary:   | Denial of Service
   | processing Cache Digest Response
Affected versions: | Squid 3.x -> 3.5.28
   | Squid 4.x -> 4.12
   | Squid 5.x -> 5.0.3
Fixed in version:  | Squid 4.13 and 5.0.4
__

CVE Assignment pending
__

Problem Description:

 Due to Improper Input Validation Squid is vulnerable to a Denial
 of Service attack against the machine operating Squid.

__

Severity:

 This problem allows a trusted peer to deliver to perform Denial
 of Service by consuming all available CPU cycles on the machine
 running Squid when handling a crafted Cache Digest response
 message.

 This attack is limited to Squid using cache_peer with cache
 digests feature.

CVSS Score of 9.5


__

Updated Packages:

This bug is fixed by Squid versions 4.13 and 5.0.4.

 In addition, patches addressing this problem for the stable
 releases can be found in our patch archives:

Squid 4:
 

 If you are using a prepackaged version of Squid then please refer
 to the package vendor for availability information on updated
 packages.

__

Determining if your version is vulnerable:

 All Squid built using --disable-cache-digests are not vulnerable.

 All Squid without cache_peer directives configured are not
 vulnerable.

 All Squid-3.x up to and including 3.5.28 using cache_peer
 directives with no-digest option configured are not vulnerable.

 All Squid-3.x up to and including 3.5.28 using cache_peer
 directives without the no-digest option configured are
 vulnerable.

 All Squid-4.x up to and including 4.12 using cache_peer
 directives with no-digest option configured are not vulnerable.

 All Squid-4.x up to and including 4.12 using cache_peer
 directives without the no-digest option configured are
 vulnerable.

 All Squid-5.x up to and including 5.0.3 using cache_peer
 directives with no-digest option configured are not vulnerable.

 All Squid-5.x up to and including 5.0.3 using cache_peer
 directives without the no-digest option configured are
 vulnerable.

__

Workaround:

Either,

 Add the no-digest option to all cache_peer lines in squid.conf

Or,

 Build Squid with --disable-cache-digests

__

Contact details for the Squid project:

 For installation / upgrade support on binary packaged versions
 of Squid: Your first point of contact should be your binary
 package vendor.

 If you install and build Squid from the original Squid sources
 then the  mailing list is your
 primary support point. For subscription details see
 .

 For reporting of non-security bugs in the latest STABLE release
 the squid bugzilla database should be used
 .

 For reporting of security sensitive bugs send an email to the
  mailing list. It's a closed
 list (though anyone can post) and security related bug reports
 are treated in confidence until the impact has been established.

__

Credits:

 This vulnerability was discovered by Lubos Uhliarik of RedHat.

 Fixed by Eduard Bagdasaryan (The Measurement Factory).

__

Revision history:

 2019-09-30 17:12:18 UTC Initial Report
 2020-07-29 20:51:58 UTC Fix committed
__
END
___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] I would like to know performance sizing aspects.

[vacheslav]

having 3GB memory with a ufdb improves performace

6.08.20 08:28, m k пишет:

Eliezer,

Squid's default setting is 1 core CPU, 16GB mem.
How many URLs(Blacklist) will degrade Squid's performance?

Also, SSL-Bump.

Thank you,
kitamura


2020年8月6日(木) 13:38 Eliezer Croitor >:


Kitamura,

About the tens of thousands of URLs, Have you considered using a
Blacklisting utility, it might lower the memory footprint.

Eliezer



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com 

*From:* squid-users mailto:squid-users-boun...@lists.squid-cache.org>> *On Behalf Of *m k
*Sent:* Thursday, August 6, 2020 7:25 AM
*To:* Amos Jeffries mailto:squ...@treenet.co.nz>>
*Cc:* squid-users@lists.squid-cache.org

*Subject:* Re: [squid-users] I would like to know performance
sizing aspects.

Amos,

Thank you for your reply.

It was very helpful.

> That number was gained before HTTPS became so popular. So YMMV
depending
> on how many CONNECT tunnels you have to deal with. That HTTPS
traffic can possibly be decrypted

> and cached but performance trade-offs are quite large.

Squid uses SSL-Bump.

I'm very worried about the internet slowing down due to https
decording. and I'm also worried about the internet slowing down
due to using Blacklist.

I load tens of thousands of URL(black list file) every time I set
up ACL.

How many requests does SSL-Bump in one second?

Thank you,

kitamura

2020年8月5日(水) 10:32 Amos Jeffries mailto:squ...@treenet.co.nz>>:

On 5/08/20 11:28 am, m k wrote:
>> We are considering to use Squid for our proxy, and would
like to know
>> performance sizing aspects.
>>
>> Current web access request averages per 1 hour are as
followings
>> Clients：30,000、
>> Page Views:141,741/hour
>> *Requests:4,893,106
>>

Okay. Requests and client count are the important numbers there.

The ~1359 req/sec is well within a default Squid capabilities,
which can
extend up to around 10k req/sec before needing careful tuning.

That number was gained before HTTPS became so popular. So YMMV
depending
on how many CONNECT tunnels you have to deal with. That HTTPS
traffic
can possibly be decrypted and cached but performance
trade-offs are
quite large.


>> We will install Squid on CentOS 8.1.  Please kindly share your
>> thoughts / advices

Whatever OS you are most comfortable with administering. Be
aware that
CentOS official Squid packages are very slow to update -
Apparently they
still have only v4.4 (8 months old) despite a 8.2 point
release only a
few weeks ago.

So you may need to be building your own from sources and/or
using other
semi-official packagers such as the ones from Eliezer at
NGTech when he
gets around to CentOS 8 packages.
  


FYI; If you find yourself having to use SSL-Bump, then we highly
recommended to follow the latest Squid releases with fairly
frequent
updates (at minimum a few times per year - worst case
monthly). If you
like CentOS you may find Fedora more suitable to track the
security
environment volatility and update churn.


>> Is there sizing methodology and tools?

There are a couple of methodologies, depending on what aspect
you are
tuning towards - and one for identifying the limitation points
to begin
a tuning process tuning.

The info you gave above is the beginning. Checking to see if your
traffic rate is reasonably within capability of a single Squid
instance.

Yours is reasonable, so next step is to get Squid running and
see where
the trouble points (if any) are.

 For more see 



>> How much resources are generally recommended for our
environment?
>>　 CPU:　 Memory:　 Disk space : Other factors to be considered
if any:
>> Do you have a generally recommended performance testing
tools? Any
>> suggested guidelines?
>>


 CPU - squid is still mostly single-process. So prioritize
faster GHz
rates over core number. Multi-core can help of course, but not
as much
as cycle speeds do. Hyper-threading is useless for Squid.

 Memory - Squid will use as much as you can give it. Let your
budget
govern this.

 Disk - Squid will happily run with no disk - or lots of la

[squid-users] [squid-announce] [ADVISORY] SQUID-2020:10 HTTP(S) Request Smuggling

[Amos Jeffries]

__

Squid Proxy Cache Security Update Advisory SQUID-2020:10
__

Advisory ID:   | SQUID-2020:10
Date:  | August 1, 2020
Summary:   | HTTP(S) Request Smuggling.
Affected versions: | Squid 2.5 -> 2.7.STABLE9
   | Squid 3.x -> 3.5.28
   | Squid 4.x -> 4.12
   | Squid 5.x -> 5.0.3
Fixed in version:  | Squid 4.13, 5.0.4
__

  
__

Problem Description:

 Due to incorrect data validation Squid is vulnerable to HTTP
 Request Smuggling attacks against HTTP and HTTPS traffic. This
 leads to cache poisoning.

__

Severity:

 This problem is serious because it allows any client, including
 browser scripts, to bypass local security and poison the proxy
 cache and any downstream caches with content from an arbitrary
 source.

CVSS Score of 9.3


__

Updated Packages:

This bug is fixed by Squid versions 4.13 and 5.0.4.

 In addition, patches addressing this problem for the stable
 releases can be found in our patch archives:

Squid 4:
 

 If you are using a prepackaged version of Squid then please refer
 to the package vendor for availability information on updated
 packages.

__

Determining if your version is vulnerable:

 All Squid with relaxed_header_parser configured "off" are not
 vulnerable.

 All Squid-3.x up to and including 3.5.28 with
 relaxed_header_parser configured to "on" or "warn" are
 vulnerable.

 All Squid-3.x up to and including 3.5.28 without
 relaxed_header_parser configured are vulnerable.

 All Squid-4.x up to and including 4.12 with relaxed_header_parser
 configured to "on" or "warn" are vulnerable.

 All Squid-4.x up to and including 4.12 without
 relaxed_header_parser configured are vulnerable.

 All Squid-5.x up to and including 5.0.3 with
 relaxed_header_parser configured to "on" or "warn" are
 vulnerable.

 All Squid-5.x up to and including 5.0.3 without
 relaxed_header_parser configured are vulnerable.

__

Workaround:

 Disable the relaxed HTTP parser in squid.conf:

relaxed_header_parser off

 Note, traffic which does not correctly obey HTTP specifications
 will be rejected instead of converted to standards compliance.

__

Contact details for the Squid project:

 For installation / upgrade support on binary packaged versions
 of Squid: Your first point of contact should be your binary
 package vendor.

 If you install and build Squid from the original Squid sources
 then the  mailing list is your
 primary support point. For subscription details see
 .

 For reporting of non-security bugs in the latest STABLE release
 the squid bugzilla database should be used
 .

 For reporting of security sensitive bugs send an email to the
  mailing list. It's a closed
 list (though anyone can post) and security related bug reports
 are treated in confidence until the impact has been established.

__

Credits:

 This vulnerability was discovered by Amit Klein of Safebreach.

 Fixed by Amos Jeffries of Treehouse Networks Ltd.

__

Revision history:

 2020-05-11 08:21:58 UTC Initial Report
 2020-07-17 17:11:50 UTC CVE Allocated
__
END
___
squid-announce mailing list
squid-annou...@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-announce
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit large downloads to autenticated users

[Service MV]

Thank you, Amos, for the clarification.
After making time for me to test some more with fast acl's I noticed that
it still didn't work. So after some more research I found out that the
problem is already reported as "Bug 4913 - Delay Pools don't work for
Tunneled traffic" which is exactly the problem I was having. HTTP traffic
is correctly limited in my tests.
For the time being I will see if I can limit it in another way until I can
fix it.

Best regards
Gabriel


El mar., 28 de jul. de 2020 a la(s) 10:26, Amos Jeffries (
squ...@treenet.co.nz) escribió:

> On 28/07/20 8:41 am, Service MV wrote:
> > Hi everybody!
> > I read in the squid mailing lists that delay_pools doesn't work in v4.x,
> > but in the documentation I don't see anything about it.
>
> * Delay pools is a fairly major feature.
>
> * "Dont work" is a very vague claim.
>
> * mailing list threads are typically started by people who don't know
> how to use a feature properly and having trouble because of that
> misunderstanding.
>
> * 4.x is an entire series of releases with many bug fixes across the
> (ongoing) year(s) long lifecycle.
>
> Draw your own conclusion about the accuracy of such statement on the
> mailing list.
>
>
>
> > I would like to know if in my SQUID 4.11 configuration with Kerberos +
> > LDAP authentication I can setup a delay_pools to limit large downloads
> > of any authenticated user.
> >
>
> Yes. That should be entirely possible.
>
>
> > This is my test configuration that I try to do, but I cannot limit the
> > downloads.
> >
> > squid.conf
> ...
> > acl auth proxy_auth REQUIRED
> > delay_pools 1
> > delay_class 1 2
> > delay_parameters 1 64000/64000 64000/64000
>
> > delay_access 1 allow auth
>
> The first problem is here. proxy_auth ACL is a "slow" type and
> delay_access only supports "fast" types.
>
> Squid-4 provides transaction annotations feature that can bridge this
> gap. It is a fast type ACL that checks for annotations set by helper
> lookups etc.
>
>   acl hasUsername note user
>   delay_access 1 allow hasUser
>   delay_access 1 deny all
>
>
>
> > http_access allow auth
>
> This should be down just above the "http_access deny all"
>
>
> > acl SSL_ports port 443
> > acl Safe_ports port 80
> > acl CONNECT method CONNECT
> > http_access deny !Safe_ports
> > http_access deny CONNECT !SSL_ports
> >
> > http_access deny all
> >
> >
>
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Need squid latest version 4.13 RPM packaged files for centos7 and x86_64 architecture

[rahul.negi]

Hi Team,

Can anyone please share squid latest stable version 4.13 RPM packaged  files 
for CentOS7  distribution and x86_64 architecture.

Thanks and Regards,
Rahul Negi


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Need squid latest version 4.13 RPM packaged files for centos7 and x86_64 architecture

[Arsalan Hussain]

 Dear Mr. Negi

Reference to email received from Squid forum regarding Squid-4.13 release
package by Mr. Amos Jeffries.

See below information. I am planning to upgrade my server by trying it soon

COPIED

On Sun, Aug 23, 2020 at 1:35 PM Amos Jeffries  wrote:

> The Squid HTTP Proxy team is very pleased to announce the availability
> of the Squid-4.13 release!
>
>
> This release is a security release resolving several issues found in
> the prior Squid releases.
>
>
> The major changes to be aware of:
>
>  * SQUID-2020:8 HTTP(S) Request Splitting
>(CVE-2020-15811)
>
> This problem is serious because it allows any client, including
> browser scripts, to bypass local security and poison the browser
> cache and any downstream caches with content from an arbitrary
> source.
>
> See the advisory for patches:
>  <
> https://github.com/squid-cache/squid/security/advisories/GHSA-c7p8-xqhm-49wv
> >
>
>
>  * SQUID-2020:9 Denial of Service processing Cache Digest Response
>(CVE pending allocation)
>
> This problem allows a trusted peer to deliver to perform Denial
> of Service by consuming all available CPU cycles on the machine
> running Squid when handling a crafted Cache Digest response
> message.
>
> This attack is limited to Squid using cache_peer with cache
> digests feature.
>
> See the advisory for patches:
>  <
> https://github.com/squid-cache/squid/security/advisories/GHSA-vvj7-xjgq-g2jg
> >
>
>
>  * SQUID-2020:10 HTTP(S) Request Smuggling
>(CVE-2020-15810)
>
> This problem is serious because it allows any client, including
> browser scripts, to bypass local security and poison the proxy
> cache and any downstream caches with content from an arbitrary
> source.
>
>
> See the advisory for patches:
>  <
> https://github.com/squid-cache/squid/security/advisories/GHSA-3365-q9qx-f98m
> >
>
>
>  * Bug 5051: Some collapsed revalidation responses never expire
>
> This bug appears as a 4xx or 5xx status response becoming the only
> response delivered by Squid to a URL when Collapsed Forwarding
> feature is used.
>
> It primarily affects Squid which are caching the 4xx/5xx status
> object since Bug 5030 fix in Squid-4.11. But may have been
> occurring for short times on any proxy with Collapsed Forwarding.
>
>
>
>  * SSL-Bump: Support parsing GREASEd (and future) TLS handshakes
>
> Chrome Browser intentionally sends random garbage values in the
> TLS handshake to force TLS implementations to cope with future TLS
> extensions cleanly. The changes in Squid-4.12 to disable TLS/1.3
> caused our parser to be extra strict and reject this TLS garbage.
>
> This release adds explicit support for Chrome, or any other TLS
> agent performing these "GREASE" behaviours.
>
>
>  * Honor on_unsupported_protocol for intercepted https_port
>
> This behaviour was one of the intended use-cases for unsupported
> protocol handling, but somehow was not enabled earlier.
>
> Squid should now be able to perform the on_unsupported_protocol
> selected action for any traffic handled by SSL-Bump.
>
>
>   All users of Squid are urged to upgrade as soon as possible.
>
>
> See the ChangeLog for the full list of changes in this and earlier
> releases.
>
> Please refer to the release notes at
> http://www.squid-cache.org/Versions/v4/RELEASENOTES.html
> when you are ready to make the switch to Squid-4
>
> This new release can be downloaded from our HTTP or FTP servers
>
>   http://www.squid-cache.org/Versions/v4/
>   ftp://ftp.squid-cache.org/pub/squid/
>   ftp://ftp.squid-cache.org/pub/archive/4/
>
> or the mirrors. For a list of mirror sites see
>
>   http://www.squid-cache.org/Download/http-mirrors.html
>   http://www.squid-cache.org/Download/mirrors.html
>
> If you encounter any issues with this release please file a bug report.
>   http://bugs.squid-cache.org/
>
>
> Amos Jeffries
> ___
> squid-announce mailing list
> squid-annou...@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-announce
>


On Mon, Aug 24, 2020 at 9:07 AM  wrote:

> Hi Team,
>
> Can anyone please share squid latest stable version 4.13 RPM packaged
>  files for CentOS7  distribution and x86_64 architecture.
>
>
>
> *Thanks and Regards,*
>
> *Rahul Negi*
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used