Entirely unsurprising. With all this complexity, HTTP2 is on par with a full TCP/IP stack. All major operating systems had decades to optimize and bulletproof these, and <i>still</i> to this day we find issues with them every now and then. What did people expect would happen when we start reinventing the wheel yet again, <i>on top of what we already have</i>?<p>And this is just the tip of the iceberg. Consider this a warm-up exercise.
I somewhat wish there was a way to test if any http2 server is vulnerable to these issues:<p>* <a href="https://godoc.org/golang.org/x/net/http2" rel="nofollow">https://godoc.org/golang.org/x/net/http2</a><p>* <a href="https://www.haproxy.com/blog/haproxy-1-9-has-arrived/" rel="nofollow">https://www.haproxy.com/blog/haproxy-1-9-has-arrived/</a><p>* <a href="https://repo1.maven.org/maven2/org/eclipse/jetty/http2/" rel="nofollow">https://repo1.maven.org/maven2/org/eclipse/jetty/http2/</a><p>* etc…<p>Larger list at <a href="https://en.wikipedia.org/wiki/HTTP/2#Server_software" rel="nofollow">https://en.wikipedia.org/wiki/HTTP/2#Server_software</a>
Cloudflare post on this: <a href="https://blog.cloudflare.com/on-the-recent-http-2-dos-attacks/" rel="nofollow">https://blog.cloudflare.com/on-the-recent-http-2-dos-attacks...</a>
Here is a server vulnerability matrix... pretty much if you are running HTTP/2 you are exposed and your vendor has a patch waiting for you.<p><a href="https://vuls.cert.org/confluence/pages/viewpage.action?pageId=56393752" rel="nofollow">https://vuls.cert.org/confluence/pages/viewpage.action?pageI...</a>
It's a nice write-up, really, but any HTTP/2 implementation should be tested with a nice packet fuzzer. Indeed, server providers should compete in the square miles of the datacenter they use to run the fuzzer. Also, the best servers should come with several defense perimeters, including one with geo-ip-directed tactic missiles. Nothing less will do.
Flow control in application protocols over TCP has been tried (in SSHv2), and it's failed. In SSHv2 flow control acts as a handbrake on all channels -- not good, though it does fix the starving of non-bulk channels by bulk channels. It's bound to fail in HTTP/2 as well.