Much as I enjoy complaining about HTTP2 getting rammed through, I am curious how much these critiques apply to 1.1.
Stream reuse (CVE-2016-0150), hpack bomb (CVE-2016-1544, CVE-2016-2525), and dependency abuse attacks are all http/2 protocol/implementation specific. The fourth, slow read attack (CVE-2016-1546) isn’t necessarily specific to http/2 but is made much less expensive to exploit because of stream multiplexing.
Multiplexing is interesting. Some time ago I made a pf rule to ban hosts that make too many connections. There’s no legit reason to make 20 req/s to my server. But some php Vuln scanners were slipping through, because they reused the same connection. With no penalty to regular traffic, I could disable keep alive and flush them out.
To return to http2, some number of admins are probably relying on some correspondence between http sessions and TCP sessions, and have firewall rules in places that limit the latter to protect the former. Everybody needs “application firewalls” now.
There’s no legit reason to make 20 req/s to my server.
…but but but i really like your blog!
and so does wget and cron. <_<;;
Notice that this will be true of any protocol that multiplexes as HTTP/2 does. Since the multiplexing provides substantial benefit for both performance and privacy (orthogonal to the new side channels, which of course are a problem), my personal feeling is that the industry should accept the cost of writing new firewall code, but try to mitigate it by making sure that we wind up with as few new multiplexing protocols as possible and that they meet a wide variety of needs.
Apropos the ssh thread, ssh has done multiplexing for a while, but it’s post auth, which limits the exposure to complete randos.
Ah, good point.
As kel says, these are bugs introduced as new features. It’s a type error to ask about their status in http 1.1. :)
They mention HPACK and its relation to crime, and indeed, the also newly announced HEIST attack works even better against http2.