Nginx Security HTTP/2 Rapid Reset DDOS Attack Vulnerability CVE-2023-44487

eva2000 · Oct 11, 2023

Cloudflare, Amazon AWS and Google announced a HTTP/2 Rapid Reset DDOS Attack vulnerability (CVE-2023-44487) that affects all web servers. Cloudflare CDN has already rolled out mitigation and protection for this vulnerability so if your Apache, Nginx, OpenLiteSpeed/Litespeed web server is behind Cloudflare with orange cloud proxy enabled, you should be protected.

HTTP/2 Rapid Reset DDOS Attack Vulnerability Fix/Mitigation

For Centmin Mod Nginx users that are not using Cloudflare orange cloud enabled proxying in front, Nginx has committed a fix but it's in their master branch (HTTP/2: per-iteration stream handling limit) and hasn't been released in Nginx 1.24 or 1.25 branches yet. They also mention how this patch fix will work in their blog post. I suspect Nginx will have versions 1.24.1 and 1.25.3 with the eventual committed fix.

Luckily, Centmin Mod Nginx supports builds from bleeding edge Nginx master branch for testing and emergencies like this. Centmin Mod centmin.sh menu option 4 can build Nginx using master branch by just inputting the Nginx version when prompted as = master

There maybe more commits for this vulnerability, so check the master branch link and use centmin.sh menu option 4 = master Nginx rebuilds as needed until official Nginx versions are released.
Code (Text):
--------------------------------------------------------
     Centmin Mod Menu 130.00beta01 centminmod.com
--------------------------------------------------------
1).  Centmin Install
2).  Add Nginx vhost domain
3).  NSD setup domain name DNS
4).  Nginx Upgrade / Downgrade
5).  PHP Upgrade / Downgrade
6).  Option Being Revised (TBA)
7).  Option Being Revised (TBA)
8).  Option Being Revised (TBA)
9).  Option Being Revised (TBA)
10). Memcached Server Re-install
11). MariaDB MySQL Upgrade & Management
12). Zend OpCache Install/Re-install
13). Install/Reinstall Redis PHP Extension
14). SELinux disable
15). Install/Reinstall ImagicK PHP Extension
16). Change SSHD Port Number
17). Multi-thread compression: zstd,pigz,pbzip2,lbzip2
18). Suhosin PHP Extension install
19). Install FFMPEG and FFMPEG PHP Extension
20). NSD Install/Re-Install
21). Data Transfer (TBA)
22). Add Wordpress Nginx vhost + Cache Plugin
23). Update Centmin Mod Code Base
24). Exit
--------------------------------------------------------
Enter option [ 1 - 24 ] 4
--------------------------------------------------------
Code (Text):
Nginx Upgrade - Would you like to continue? [y/n] y

Current Nginx Version: 1.25.2 (041023-060220-almalinux9-384e3e2-br-659b4b3)

Install which version of Nginx? (version i.e. type 1.25.2): master

Do you still want to continue? [y/n] y
End result is Centmin Mod Nginx built on master branch 1.25.3 version with the mitigation fix for HTTP/2 Rapid Reset DDOS Attack vulnerability just ~2hrs after Nginx committed the patch for CVE-2023-44487

nginx -V
nginx version: nginx/1.25.3 (101023-135823-almalinux9-333e53e-br-a71f931)
built by gcc 12.2.1 20221121 (Red Hat 12.2.1-7) (GCC)
Click to expand...

Nginx folks have a blog for mitigation via Nginx configuration too https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

This blog centers on a vulnerability that was recently discovered related to the HTTP/2 protocol. Under certain conditions, this vulnerability can be exploited to execute a denial-of-service attack on NGINX Open Source, NGINX Plus, and related products that implement the server-side portion of the HTTP/2 specification. To protect your systems from this attack, we’re recommending an immediate update to your NGINX configuration.

The Problem with HTTP/2 Stream Resets
After establishing a connection with a server, the HTTP/2 protocol allows clients to initiate concurrent streams for data exchange. Unlike previous iterations of the protocol, if an end user decides to navigate away from the page or halt data exchange for any other reason, HTTP/2 provides a method for canceling the stream. It does this by issuing an RST_STREAM frame to the server, saving it from executing work needlessly.

The vulnerability is exploited by initiating and rapidly canceling a large number of HTTP/2 streams over an established connection, thereby circumventing the server’s concurrent stream maximum. This happens because incoming streams are reset faster than subsequent streams arrive, allowing the client to overload the server without ever reaching its configured threshold.

Impact on NGINX
For performance and resource consumption reasons, NGINX limits the number of concurrent streams to a default of 128 (see http2_max_concurrent_streams). In addition, to optimally balance network and server performance, NGINX allows the client to persist HTTP connections for up to 1000 requests by default using an HTTP keepalive (see keepalive_requests).

By relying on the default keepalive limit, NGINX prevents this type of attack. Creating additional connections to circumvent this limit exposes bad actors via standard layer 4 monitoring and alerting tools.

However, if NGINX is configured with a keepalive that is substantially higher than the default and recommended setting, the attack may deplete system resources. When a stream reset occurs, the HTTP/2 protocol requires that no subsequent data is returned to the client on that stream. Typically, the reset results in negligible server overhead in the form of tasks that gracefully handle the cancellation. However, circumventing NGINX’s stream threshold enables a client to take advantage of this overhead and amplify it by rapidly initiating thousands of streams. This forces the server CPU to spike, denying service to legitimate clients.
Click to expand...

Steps for Mitigating Attack Exposure
As a fully featured server and proxy, NGINX provides administrators with powerful tools for mitigating denial-of-service attacks. It is our recommendation that the following updates are made to NGINX configuration files, minimizing the server’s attack surface:

keepalive_requests should be kept at the default setting of 1000 requests

http2_max_concurrent_streams should be kept at the default setting of 128 streams

limit_conn enforces a limit on the number of connections allowed from a single client. This directive should be added with a reasonable setting balancing application performance and security.

limit_req enforces a limit on the number of requests that will be processed within a given amount of time from a single client. This directive should be added with a reasonable setting balancing application performance and security.

Click to expand...

How We’re Responding
We experimented with multiple mitigation strategies that helped us gain an understanding into how this attack could impact our wide range of customers and users. While this research confirmed that NGINX is already equipped with all the necessary tools to avoid the attack, we wanted to take additional steps to ensure that users who do need to configure NGINX beyond recommended specifications are able to do so.

Our investigation yielded a method for improving server resiliency under various forms of flood attacks that are theoretically possible over the HTTP/2 protocol. To address this, we will be issuing a patch that increases stability under these conditions tomorrow. Please check back here for updates.

How This Patch Will Work
To ensure the early detection of flood attacks on NGINX, a limit will be imposed on the number of new streams that can be introduced within one event loop. This limit will be set to twice the value configured using the http2_max_concurrent_streams directive. The limit will be applied even if the maximum threshold is never reached, like when streams are reset right after sending the request (as in the case of this attack).

Affected Products
This vulnerability impacts the NGINX HTTP/2 module (ngx_http_v2_module). For information about your specific NGINX or F5 product that might be affected, please visit: https://my.f5.com/manage/s/article/K000137106.

For more information on CVE-2023-44487 – HTTP/2 Rapid Reset Attack, please see: https://www.cve.org/CVERecord?id=CVE-2023-44487

Acknowledgements
We would like to recognize Cloudflare, Amazon, and Google for their part in the discovery and collaboration in identifying and mitigating this vulnerability.
Click to expand...

From Cloudflare blog https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

Starting on Aug 25, 2023, we started to notice some unusually big HTTP attacks hitting many of our customers. These attacks were detected and mitigated by our automated DDoS system. It was not long however, before they started to reach record breaking sizes — and eventually peaked just above 201 million requests per second. This was nearly 3x bigger than our previous biggest attack on record.

Concerning is the fact that the attacker was able to generate such an attack with a botnet of merely 20,000 machines. There are botnets today that are made up of hundreds of thousands or millions of machines. Given that the entire web typically sees only between 1–3 billion requests per second, it's not inconceivable that using this method could focus an entire web’s worth of requests on a small number of targets.
Click to expand...

This attack was made possible by abusing some features of the HTTP/2 protocol and server implementation details (see CVE-2023-44487 for details). Because the attack abuses an underlying weakness in the HTTP/2 protocol, we believe any vendor that has implemented HTTP/2 will be subject to the attack. This included every modern web server. We, along with Google and AWS, have disclosed the attack method to web server vendors who we expect will implement patches. In the meantime, the best defense is using a DDoS mitigation service like Cloudflare’s in front of any web-facing web or API server.
Click to expand...

From https://blog.cloudflare.com/zero-day-rapid-reset-http2-record-breaking-ddos-attack/

Earlier today, Cloudflare, along with Google and Amazon AWS, disclosed the existence of a novel zero-day vulnerability dubbed the “HTTP/2 Rapid Reset” attack. This attack exploits a weakness in the HTTP/2 protocol to generate enormous, hyper-volumetric Distributed Denial of Service (DDoS) attacks. Cloudflare has mitigated a barrage of these attacks in recent months, including an attack three times larger than any previous attack we’ve observed, which exceeded 201 million requests per second (rps). Since the end of August 2023, Cloudflare has mitigated more than 1,100 other attacks with over 10 million rps — and 184 attacks that were greater than our previous DDoS record of 71 million rps.

This zero-day provided threat actors with a critical new tool in their Swiss Army knife of vulnerabilities to exploit and attack their victims at a magnitude that has never been seen before. While at times complex and challenging to combat, these attacks allowed Cloudflare the opportunity to develop purpose-built technology to mitigate the effects of the zero-day vulnerability.

If you are using Cloudflare for HTTP DDoS mitigation, you are protected. And below, we’ve included more information on this vulnerability, and resources and recommendations on what you can do to secure yourselves.
Click to expand...

Deconstructing the attack: What every CSO needs to know
In late August 2023, our team at Cloudflare noticed a new zero-day vulnerability, developed by an unknown threat actor, that exploits the standard HTTP/2 protocol — a fundamental protocol that is critical to how the Internet and all websites work. This novel zero-day vulnerability attack, dubbed Rapid Reset, leverages HTTP/2’s stream cancellation feature by sending a request and immediately canceling it over and over.

By automating this trivial “request, cancel, request, cancel” pattern at scale, threat actors are able to create a denial of service and take down any server or application running the standard implementation of HTTP/2. Furthermore, one crucial thing to note about the record-breaking attack is that it involved a modestly-sized botnet, consisting of roughly 20,000 machines. Cloudflare regularly detects botnets that are orders of magnitude larger than this — comprising hundreds of thousands and even millions of machines. For a relatively small botnet to output such a large volume of requests, with the potential to incapacitate nearly any server or application supporting HTTP/2, underscores how menacing this vulnerability is for unprotected networks.

Threat actors used botnets in tandem with the HTTP/2 vulnerability to amplify requests at rates we have never seen before. As a result, our team at Cloudflare experienced some intermittent edge instability. While our systems were able to mitigate the overwhelming majority of incoming attacks, the volume overloaded some components in our network, impacting a small number of customers’ performance with intermittent 4xx and 5xx errors — all of which were quickly resolved.

Once we successfully mitigated these issues and halted potential attacks for all customers, our team immediately kicked off a responsible disclosure process. We entered into conversations with industry peers to see how we could work together to help move our mission forward and safeguard the large percentage of the Internet that relies on our network prior to releasing this vulnerability to the general public.

We cover the technical details of the attack in more detail in a separate blog post: HTTP/2 Rapid Reset: deconstructing the record-breaking attack.
Click to expand...

More HTTP/2 Rapid Reset DDOS Attack Vulnerability coverage:

https://cloud.google.com/blog/produ...works-the-novel-http2-rapid-reset-ddos-attack

https://cloud.google.com/blog/produ...st-ddos-attack-peaking-above-398-million-rps/ - wow they got hit with 398 million requests per second attack!

https://www.bleepingcomputer.com/ne...id-reset-zero-day-attack-breaks-ddos-records/

https://msrc.microsoft.com/blog/202...enial-of-service-ddos-attacks-against-http/2/

eva2000 · Oct 11, 2023

eva2000 said: ↑

For Centmin Mod Nginx users that are not using Cloudflare orange cloud enabled proxying in front, Nginx has committed a fix but it's in their master branch (HTTP/2: per-iteration stream handling limit) and hasn't been released in Nginx 1.24 or 1.25 branches yet. They also mention how this patch fix will work in their blog post. I suspect Nginx will have versions 1.24.1 and 1.25.3 with the eventual committed fix.
Click to expand...

Found more response/commentary for CVE-2023-44487 by Maxim Dounin from Nginx for this at https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html

To clarify:

There is FUD being spread that nginx is vulnerable to
CVE-2023-44487.

We do not consider nginx to be affected by this issue. In the
default configuration, nginx is sufficiently protected by the
limit of allowed requests per connection (see
http://nginx.org/r/keepalive_requests for details), so an attacker
will be required to reconnect very often, making the attack
obvious and easy to stop at the network level. And it is not
possible to circumvent the max concurrent streams limit in nginx,
as nginx only allows additional streams when previous streams are
completely closed.

Further, additional protection can be implemented in nginx by
using the "limit_req" directive, which limits the rate of requests
and rejects excessive requests.

Overall, with the handling as implemented in nginx, impact of
streams being reset does no seem to be significantly different
from impacts from over workloads with large number of requests
being sent by the client, such as handling of multiple HTTP/2
requests or HTTP/1.x pipelined requests.

Nevertheless, we've decided to implemented some additional
mitigations which will help nginx to detect such attacks and drop
connections with misbehaving clients faster. Hence the patch.
Click to expand...

Seems some miscommunication from F5 folks https://mailman.nginx.org/pipermail/nginx-devel/2023-October/2YGF3BG7S47VPUNQJ3D5S6FODPMSAX4A.html

I'm not "internally to F5", I'm an independent developer. This
was discussed within nginx security team, with other nginx
developers, and the conclusion is that nginx is not affected.

I have no idea why F5 decided to include nginx as affected in
their advisory, who did this, and why. This is incorrect and
should be fixed. I've already pinged them, and hopefully they
will fix this.
Click to expand...

> Ultimately,
> though, I would assume that keepalive at 100 is also still not
> enough to *fully* protect against this, therefore at the core
> "NGINX is still vulnerable to this CVE despite mitigations
> already being in place for default configuration values and
> options" is the interpretation, which means yes NGINX is in fact
> affected by this *in non-default configurations*, which means
> that it *is* still vulnerable to the CVE. Mitigations don't
> mean "fixed" or "not affected" in the strictest interpretation
> of languages and what means what.

As often the case for DoS vulnerabilities, you cannot be *fully*
protected, since there is a work to do anyway. As long as nginx
is configured to serve HTTP requests, it can be loaded with
serving HTTP requests, and maximum possible load depends on the
configurations, including various builtin limits, such as
keepalive_requests and http2_max_concurrent_streams, and DoS
mitigations which needs to be explicitly configured, such as
limit_req and limit_conn.

As already said, in this case the work nginx is willing to do is
no different from other workloads, such as with normal HTTP/2
requests or HTTP/1.x requests. As such, nginx is not considered
to be affected by this issue.
Click to expand...

eva2000 · Oct 13, 2023

eva2000 said: ↑

Luckily, Centmin Mod Nginx supports builds from bleeding edge Nginx master branch for testing and emergencies like this. Centmin Mod centmin.sh menu option 4 can build Nginx using master branch by just inputting the Nginx version when prompted as = master

There maybe more commits for this vulnerability, so check the master branch link and use centmin.sh menu option 4 = master Nginx rebuilds as needed until official Nginx versions are released.
Click to expand...

Added Centmin Mod Nginx master branch build automated testing for EL8/EL9 as well for AlmaLinux vs Rocky Linux vs Oracle Linux, so now for Nginx tests, I automate h2load HTTP/2 testing against Nginx OpenSSL 1.1.1 vs Nginx OpenSSL 3.0 vs Nginx QuicTLS vs Nginx BoringSSL vs Nginx OpenSSL 1.1.1 with official zlib instead of Cloudflare zlib vs Nginx master branch

It looks like the Nginx 1.25.3 master branch patch for HTTP/2 Rapid Reset and other updates, improved h2load HTTP/2 benchmark performance over Nginx 1.25.2 latest public mainline version on 2x CPU Azure server running an Intel Xeon Platinum 8370C CPU @ 2.80GHz running AlmaLinux 8.8 with custom 5.15 Linux Kernel
Code (Text):
5.15.0-1047-azure
AlmaLinux release 8.8 (Sapphire Caracal)

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               106
Model name:          Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz
Stepping:            6
CPU MHz:             2793.438
BogoMIPS:            5586.87
Hypervisor vendor:   Microsoft
Virtualization type: full
L1d cache:           48K
L1i cache:           32K
L2 cache:            1280K
L3 cache:            49152K
NUMA node0 CPU(s):   0,1
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear

CPU Flags
 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear
 
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
0   0    0      0    0:0:0:0       yes
1   0    0      1    1:1:1:0       yes

              total        used        free      shared  buff/cache   available
Mem:           6932        1377         443          43        5111        5201
Low:           6932        6488         443
High:             0           0           0
Swap:          4095          22        4073

Filesystem      Size  Used Avail Use% Mounted on
overlay          84G   73G   11G  88% /
tmpfs           3.4G     0  3.4G   0% /sys/fs/cgroup
tmpfs            64M     0   64M   0% /dev
shm              64M     0   64M   0% /dev/shm
tmpfs            64M  6.5M   58M  11% /run
tmpfs           4.0M     0  4.0M   0% /run/lock
devtmpfs        3.4G     0  3.4G   0% /dev/tty
/dev/root        84G   73G   11G  88% /etc/hosts
tmpfs           3.4G     0  3.4G   0% /proc/acpi
tmpfs           3.4G     0  3.4G   0% /proc/scsi
tmpfs           3.4G     0  3.4G   0% /sys/firmware
tmpfs           3.4G  8.0K  3.4G   1% /tmp
FYI, Centmin Mod Nginx defaults to OpenSSL 1.1.1 with Cloudflare zlib performance forked library unless otherwise stated. You can see how official zlib is much slower than Cloudflare zlib performance forked Nginx build. Below are h2load HTTP/2 benchmark tests with Centmin Mod 130.00beta01's Nginx

Jon Snow · Oct 13, 2023

So I just type:
Code (Text):
master
When prompted to enter the nginx version and not a specific nginx version followed by "master"?

Do you know anyone who has been affected by this?

eva2000 · Oct 13, 2023

Jon Snow said: ↑

When prompted to enter the nginx version and not a specific nginx version followed by "master"?
Click to expand...

Yup. Don't know of any Centmin Mod users impacted but there's up to 100,000 web sites that use Centmin Mod AFAIK, so who knows.

Itworx4me · Oct 15, 2023

I tried running the master version of nginx and it crashed nginx. Had to revert back to 1.25.2 in order to access my site. Not sure why....

eva2000 · Oct 15, 2023

Itworx4me said: ↑

I tried running the master version of nginx and it crashed nginx. Had to revert back to 1.25.2 in order to access my site. Not sure why....
Click to expand...

Crashed is a vague term, describe the specific symptoms and error messages i.e. check nginx config check command's output
Code (Text):
nginx -t
But might be unrelated to Cloudflare zlib library breaking change for Nginx compiles at https://community.centminmod.com/threads/24139/

So always run cmupdate command BEFORE running centmin.sh menu options to ensure you have latest Centmin Mod code updates first.

Andy · Oct 20, 2023

Same issue with @Itworx4me

# nginx -t
nginx: [emerg] unknown directive "pagespeed" in /usr/local/nginx/conf/pagespeedadmin.conf:9
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

I have to comment out this line in the nginx.conf file and do nprestart to restart nginx.
#include /usr/local/nginx/conf/pagespeedadmin.conf;

eva2000 · Oct 20, 2023

Andy said: ↑

Same issue with @Itworx4me

# nginx -t
nginx: [emerg] unknown directive "pagespeed" in /usr/local/nginx/conf/pagespeedadmin.conf:9
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

I have to comment out this line in the nginx.conf file and do nprestart to restart nginx.
#include /usr/local/nginx/conf/pagespeedadmin.conf;
Click to expand...

ngx_pagespeed should be disabled in latest 124.00stable and 130.00beta01 beta versions of Centmin Mod by default already. What version of Centmin Mod are you using.

buik · Oct 21, 2023

eva2000 said: ↑

Found more response/commentary for CVE-2023-44487 by Maxim Dounin from Nginx for this at https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html
Click to expand...

We do not consider nginx to be affected by this issue.
Click to expand...

Just a strange CVE. First, a programmer at Nginx wrote that their product is not subject to, only to release a patch for the paid Nginx Plus edition. But not for the open-source version, as of today (same source code).

https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

Even third parties have already released a patch. And even Red Hat.
Who tend to be relatively conservative in releasing patches and prefer to test it a bit longer
(better safe than sorry principle).

https://gitlab.com/redhat/centos-stream/rpms/nginx/-/commit/ba15c0f4a408e728b64b92d6d478ec8afac68732

https://access.redhat.com/errata/RHSA-2023:5713

Now in all honesty, I have to admit that I didn't put super much time into this case, I am simply far too busy. But what is truth? Remarkable, to say the least.

buik · Oct 21, 2023

@eva2000 Something is going wrong on your forum apparently? My response is published simultaneously, multiple times.

eva2000 · Oct 21, 2023

buik said: ↑

@eva2000 Something is going wrong on your forum apparently? My response is published simultaneously, multiple times.
Click to expand...

Yeah that sometimes happens heh

buik said: ↑

Just a strange CVE. First, a programmer at Nginx wrote that their product is not subject to, only to release a patch for the paid Nginx Plus edition. But not for the open-source version, as of today (same source code).
Click to expand...

The patch nginx has in master branch is to further enhance mitigation and not to fix it according to them, they consider nginx default settings out of box enough to mitigate.

But yeah I would consider nginx impacted myself.

Andy · Oct 21, 2023

eva2000 said: ↑

ngx_pagespeed should be disabled in latest 124.00stable and 130.00beta01 beta versions of Centmin Mod by default already. What version of Centmin Mod are you using.
Click to expand...

Centmin Mod Menu 130.00beta01 centminmod.com
Did I fix that issue correctly or is there the right way to do it?

buik · Oct 21, 2023

eva2000 said: ↑

they consider nginx default settings out of box enough to mitigate.

But yeah I would consider nginx impacted myself.
Click to expand...

Exactly this. The default settings that should provide enough resistance. Only to then do release an update to their paid service. And the free edition doesn't. Nice that the patch is in git though, that is of no use to the average user.

We've talked about this before. It just goes to show where the priority is at Nginx, these days.

eva2000 · Oct 21, 2023

buik said: ↑

We've talked about this before. It just goes to show where the priority is at Nginx, these days.
Click to expand...

Money talks as expected as that money keeps Nginx free open source running. I have paid clients hire me to extend and customise Centmin Mod for the specific needs

But after developing Centmin Mod, I understand something that I didn't before, as your project gets wider adoption, you have to be more cautious releasing new features or code as the impact is greater once you have more users. A controlled release to smaller segments can be more beneficial to tackling issues that may arise. Just so happens for Nginx that smaller group is also their paid Nginx Plus customers

Andy said: ↑

Did I fix that issue correctly or is there the right way to do it?
Click to expand...

Yup that fixes it.

buik · Oct 22, 2023

eva2000 said: ↑

Money talks as expected as that money keeps Nginx free open source running. I have paid clients hire me to extend and customise Centmin Mod for the specific needs
Click to expand...

Clients asking for customization and/ or custom-made features, and you ask those customers for a fee is obvious.

I see a substantial difference here, positively in your favor.
You did release a fix, almost instantaneously (also) on the forum.

"Security issues will be updated in CentOS Stream after they are solved in the current RHEL release"
Click to expand...

Nginx does the exact opposite. You could get their beta (mainline) bits. But should there be a CVE, Nginx plus takes priority. Exactly the same with CentOS Stream and RHEL.

eva2000 · Oct 22, 2023

Was just reading Nginx's master commits when you replied to this thread https://hg.nginx.org/nginx/shortlog/default Looks like they're adding additional QUIC and HTTP/2 commits to the master branch for 1.25.3

buik · Oct 22, 2023

eva2000 said: ↑

Was just reading Nginx's master commits when you replied to this thread https://hg.nginx.org/nginx/shortlog/default Looks like they're adding additional QUIC and HTTP/2 commits to the master branch for 1.25.3
Click to expand...

QUIC is a complete disaster.

Not so much at the hands of team Nginx. But those Goof's from OpenSSL. Who despite much opposition from the community. Still stubbornly reinvent the wheel with their own QUIC implementation.

While there was a commit ready to insert the full feature right away.
The only logical reason I can think of to reject that: OpenSSL is largely made up of freelancers. And they can write hours now and with a ready-made commit so they can't.

And yes QUIC on Nginx can be solved with quictls, but I don't believe the gross of users, know about that.

eva2000 · Oct 22, 2023

buik said: ↑

Not so much at the hands of team Nginx. But those Goof's from OpenSSL. Who despite much opposition from the community. Still stubbornly reinvent the wheel with their own QUIC implementation.
Click to expand...

+1. Not to mention the OpenSSL 3.0 and 3.1 performance regressions compared to OpenSSL 1.1.1 https://github.com/openssl/openssl/issues/17064. Though for Nginx OpenSSL usage, there difference for HTTP/2 at least isn't that bad as my testing is single threaded. But still OpenSSL 1.1.1 > OpenSSL 3.1 > OpenSSL 3.0 in terms of best to worst performers.

Though these days, I am not as concerned. Just put site behind Cloudflare and let it do the HTTP/3 QUIC on their CDN edge servers

buik · Oct 22, 2023

eva2000 said: ↑

But still OpenSSL 1.1.1 > OpenSSL 3.1 > OpenSSL 3.0 in terms of best to worst performers.

Though these days, I am not as concerned. Just put site behind Cloudflare and let it do the HTTP/3 QUIC on their CDN edge servers
Click to expand...

Reason: I can't see the logs anymore, to do that, I need to have Cloudflare Pro, at $20 a month. For many very small sites, that's just not worth it, it's more than 4x what I pay for hosting.
Click to expand...

I'm a little subscription tired these days. They plop everything behind subscription form these days. That you have to depend on a far too large party just to play a decent movie, delivering a simple package without unnecessary costs, or in the website area that you're paying through the nose; Because a software party is arguing over Quic. While the code is already there. Too much politics. They are just pussyfooting around.

Source: https://nitter.net/jdevalk/status/1633028813880799233#m

Log in / Register

Forums

Join the community today

Nginx Security HTTP/2 Rapid Reset DDOS Attack Vulnerability CVE-2023-44487

eva2000 Administrator Staff Member

HTTP/2 Rapid Reset DDOS Attack Vulnerability Fix/Mitigation

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Jon Snow Active Member

eva2000 Administrator Staff Member

Itworx4me Premium Member Premium Member

eva2000 Administrator Staff Member

Andy Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

Andy Active Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

.

Log in / Register

Useful Searches

Join the community today

Nginx Security HTTP/2 Rapid Reset DDOS Attack Vulnerability CVE-2023-44487

eva2000 Administrator Staff Member

HTTP/2 Rapid Reset DDOS Attack Vulnerability Fix/Mitigation

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Jon Snow Active Member

eva2000 Administrator Staff Member

Itworx4me Premium Member Premium Member

eva2000 Administrator Staff Member

Andy Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

Andy Active Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

.