
HTTP/2 Denial of Service Advisory - rdli
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md
======
iforgotpassword
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 _still_ 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, _on top of what we already have_?

And this is just the tip of the iceberg. Consider this a warm-up exercise.

~~~
the_duke
We can happily look forward to HTTP/3 then.

It actually IS a full stack...

~~~
persistent
Putting HTTP/3 on a userspace QUIC stack solves a number of these problems.

~~~
throwaway2048
HTTP/2 already is userspace.

------
iampims
I somewhat wish there was a way to test if any http2 server is vulnerable to
these issues:

* [https://godoc.org/golang.org/x/net/http2](https://godoc.org/golang.org/x/net/http2)

* [https://www.haproxy.com/blog/haproxy-1-9-has-arrived/](https://www.haproxy.com/blog/haproxy-1-9-has-arrived/)

* [https://repo1.maven.org/maven2/org/eclipse/jetty/http2/](https://repo1.maven.org/maven2/org/eclipse/jetty/http2/)

* etc…

Larger list at
[https://en.wikipedia.org/wiki/HTTP/2#Server_software](https://en.wikipedia.org/wiki/HTTP/2#Server_software)

~~~
Exuma
I'm also wondering about golang http2

~~~
140am
[https://github.com/golang/go/issues/33631](https://github.com/golang/go/issues/33631)
(this is part of go 1.12.8 and 1.11.13 which got released because of this
today)

------
judge2020
Cloudflare post on this: [https://blog.cloudflare.com/on-the-recent-
http-2-dos-attacks...](https://blog.cloudflare.com/on-the-recent-http-2-dos-
attacks/)

------
netsectoday
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.

[https://vuls.cert.org/confluence/pages/viewpage.action?pageI...](https://vuls.cert.org/confluence/pages/viewpage.action?pageId=56393752)

~~~
Matthias247
A little bit disappointed they didn't test my implementation
([https://github.com/Matthias247/http2dotnet](https://github.com/Matthias247/http2dotnet)).
It's more or less the only feature complete standalone HTTP/2 implementation
for .NET - but somehow that ecosystem seams to be too niche so that nobody
ever got interested in using it.

Actually I feel like it avoids most if not all of the described issues.
async/await in combination with the design principle of always exercising
backpressure on the client and having no internal queues goes a long way in
this.

------
jrockway
Envoy appears to have been updated today to 1.11.1 to mitigate some of these
issues. I upgraded and have not experienced any problems yet.

------
mholt
Caddy is patched. v1.0.2.
[https://github.com/caddyserver/caddy/releases/tag/v1.0.2](https://github.com/caddyserver/caddy/releases/tag/v1.0.2)

------
dsign
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.

~~~
kodablah
For some of the DOS things, I'm not sure fuzzers would be that effective. For
the flooding issues, it's about quantity and frequency instead of how the
packet is crafted.

------
mjevans
Is there a better list of fixed versions for E.G. Apache / Lighttpd (n/a No
http/2 support) / Nginx?

~~~
m11r
For nginx, versions 1.16.1+ and 1.17.3+ from upstream fix at least three of
the vulnerabilities (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516), _however_
if you use a version provided by a distribution’s repositories (e.g., nginx
1.16 included with Ubuntu 18.04 LTS) you’ll need to watch for those security
advisories and fixes separately which may have different version numbers due
to the backporting.

------
cryptonector
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.

~~~
ryacko
I wish application-level flow control would be paired with a database of
internet speeds per subnet. They already track everything else, my connection
shouldn’t repeatedly slow because the congestion algorithm doesn’t know my
maximum download speed.

~~~
cryptonector
Not subnet but link. Anyways, that can't quite work because even if you could
make that accurate there's still congestion to worry about. What you want is
something like explicit congestion control with IP options for reporting max
path bandwidth or whatever, but that too is susceptible to spoofing and
DoSing.

~~~
ryacko
No, not explicit congestion control, the amount of entropy in what internet
plan a user has (outside of a lossy CDMA-type connection) is fairly low. The
sender should set window sizes, not assume ISPs should set an IP-level flag.
Probes for speeds should be less aggressive since it isn’t unknown how fast a
typical connection is.

Not, link, but subnet, since dynamic IPs exist. IP addresses are usually
assigned geographically.

------
jedisct1
Of course this affects DoH servers, too.

