Important to note that unless your Nginx instance has a special (read: very high) keepalive limit configured, Nginx has a fairly reasonable defense against HTTP/2 rapid reset attack by default, as the article says. Still, interesting to see the response to these attacks.
I’m stuck trying to figure out if this is technically desired behavior or not. If you were retroactively designing http/2 with this knowledge, would you have done anything different?
FYI this is for the commercial nginx product, hastily purchased by F5 a few years back when software load balancers were annihilating their hardware offering.<p>Curious to see f5 still playing games with their own cve disclosure on the bigip product though...assigning it a mitre cw400 is just lying.<p><a href="https://my.f5.com/manage/s/article/K000137106" rel="nofollow noreferrer">https://my.f5.com/manage/s/article/K000137106</a>
From some first-hand experience over the last few months… these suggestions and patch will help prevent a single client from overwhelming an NGINX server, but it will do little to stop even a modest botnet from generating enough requests to be a problem. Keeping some state on IPs and downgrading those that exceed limits to HTTP/1.1 I believe is the only effective defense. Tuning those thresholds to get them right is… challenging.
Hehe, when I heard about the attack a couple of days ago I was interested to know if Nginx was affected and did a search on Google for the CVE of that attack followed by the name of Nginx.<p>I didn’t find anything relevant so I assumed that Nginx was not affected.<p>Turns out that was not a good assumption :p
If someone asked me how to "speed up the web", I would not suggest "use HTTP/2".
I would remove ads and other garbage. As a decades long non-popular browser and TCP client user, I can testify this works very effectively. I prefer to have full control over the resources that I request, whether text or binary, so no auto-loading resources, no Javascript-requested resources and no HTTP/2 "server push". The clients I use do not auto-load resources, run Javascript nor carry out "server push". Works great for me. Web is not slow.<p>According to HTTP/2 proponents, the protocol originated at an online advertising services company and was developed by companies that profit from sale and delivery of online advertising, HTTP/2 was designed to "speed up the web".<p>I respect that opinions on HTTP/2 may differ. If someone loves HTTP/2, then I respect that opinion. In return I ask that others respect opinions that may differ from their own, including mine. NB. This comment speaks only for the web user submitting it. It does not speak for other web users. IMHO, no HN commenter can speak for other web users either. Thank you.
Just use HTTP/1.1, it's the final protocol.<p>Nothing Google or Microsoft does will dethrone it.<p>Forget the browser; use a C or Java client and HTTP.<p>If they block port 80, just use another port.<p>They cannot win.