There is a difference between an application being innately vulnerable and a user configuration exposing a vulnerability.
Interestingly enough, HAProxy seems to have the same mitigation:
> Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack.
That is, if I read it correctly, default configuration is safe and you can use configuration of stream limits to ensure you are not vulnerable, but they are saying HAProxy is not vulnerable...at least in the title. Later on they soften the language:
I think the important distinction is ‘a user may plausibly have this non default configure’ vs ‘this config is obscure almost nobody will be running it this way’
I am not sure I understand how stream limit configuration between two L4/L7 load balancers is meaningfully different. In my mind, either the configuration of stream limits is a vulnerability for all L4/L7 load balancers that offer that configuration or it's not for all of them.
If one doesn't _offer_ configuration of stream limits and therefore is not susceptible to user misconfiguration, then I would get the distinction. But as I understand it both HAProxy and NGINX have the same configuration options which _could_ be vulnerable if configured poorly by the user. One is just putting a lot more positive spin on it.
Nginx and HAProxy work around the issue in different ways.
Nginx by default simply kills the entire connection after 1000 requests. With this attack, that's two packets. This severely limits its amplification and basically makes the bypass of the concurrent stream limit a moot point - unless you manually increased the requests-until-killed count.
HAProxy avoids the issue by deviating from the specification. You are supposed to only count active requests towards the concurrent stream limit and ignore cancelled ones, but HAProxy does count cancelled requests and only removes them from the stream count once their resources are fully released. In practice this means the attack isn't any worse than regular http/2 requests.
The protocol-level bug still exists, but in both cases it just can't be used to launch an attack anymore.
OP mentioned they didn't find Nginx listed on the CVE, and the reply said
>If you read the article, you'll see that the default configuration is not affected.
Which, in the context of OPs comment, implies that the CVE wouldn't be associated because the default config is not affected.
Hence my reply that CVEs don't care whether its default config or not. If there is a CVE associated with the program, there is a CVE associated with the program, rare config or not.
Interestingly enough, HAProxy seems to have the same mitigation:
> Until HAProxy dips below the configured stream limit again, new stream creation remains pending—regular timeouts eventually apply and the stream is cut if the situation does not resolve itself. This can occur during an attack.
https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-...
That is, if I read it correctly, default configuration is safe and you can use configuration of stream limits to ensure you are not vulnerable, but they are saying HAProxy is not vulnerable...at least in the title. Later on they soften the language:
> HAProxy remains resistant to HTTP/2 Rapid Reset