Does this recent http2 CVE affect this package?

[cartazio]

Hello!
I was recently reading an article about recent ddos strategies that exploit the http2 protocol https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/, and I was curious if haskells http2 package is impacted. I looked at the changelog and I don’t see mention so I figured I should ask!

[kazu-yamamoto]

Can we work around this issue by providing a rate limit for RST?
It's very easy to implement because we already have limits for Settings and empty frames.

[cartazio]

My fuzzy understanding it that the rst limiting is just part of it.

https://nvd.nist.gov/vuln/detail/CVE-2023-44487 Has links to the corresponding tickets for many widely used impls, and it may be helpful to look at what the patches in other platforms.

My naive understanding is rate limit the resets is part of it. But that there’s another rate limiting parameter that’s needed

[kazu-yamamoto]

v4.2.1 has been released.

[cartazio]

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack Talks about the other issues as refinements that try to circumvent the baseline mitigations

[kazu-yamamoto]

IETF is discussing this: https://martinthomson.github.io/h2-stream-limits/draft-thomson-httpbis-h2-stream-limits.html

[kazu-yamamoto]

I'm afraid that the rate limit (4 RSTs per second) is too small for normal communication.
I would increase the rate and introduce a delayed mechanism to decrease the number of concurrency.
This can be easily implemented with getSystemTimerManager and registerTimeout.

[cartazio]

. I trust your judgment and experience on this. I just wanted to make sure this matter was made visible.

[bjin]

I'm afraid that the rate limit (4 RSTs per second) is too small for normal communication.

Does this mean that the latest release (4.2.2) is not recommended for production use?

[kazu-yamamoto]

v4.2.2 is much more safer than the other versions.
So, highly recommended.
When over-rate RSTs come, the connection is closed.
So the rapid RST attack does not work.
Normal browsers reconnect if necessary.
What I want to say in the previous comment is there might be better way to handle many RSTs from normal browsres (e.g. pressing the stop button while downloading many stuffs).

[kazu-yamamoto]

#95 told me the followings:

• In many cases, the connection is terminated when a RST_STREAM frame is received. So, Haskell http2 library is tolerant to the rapid reset attack originally.
• The exception is the case of (HalfClosedRemote, NoError). To create this situation, a DATA frame must set end of stream. In this case, the rate control introduced recently surely works.

So, I think that the current implementation is good enough.