Hi Willy. Am 14.08.19 um 22:10 schrieb Willy Tarreau: > Hi again, > > small update on this below.
Thank you for your update. Regards aleks > On Tue, Aug 13, 2019 at 10:50:46PM +0200, Willy Tarreau wrote: >> Hi Aleks, >> >> On Tue, Aug 13, 2019 at 07:02:49PM +0000, Aleksandar Lazic wrote: >>> Have anyone seen this and maybe some information is haproxy vulnerable >>> against this attacks? >>> >>> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md >> >> Yes I had a look after being kindly notified by Piotr. In practice almost >> all of them are irrelevant in our case, either because the processing cost >> is trivial (e.g. RST_STREAM, PING, SETTINGS, empty frames...) or because >> we don't have the required feature (priority, push_promise). The one I'd >> like to have a deeper look at is the 1-byte window increments, which may >> result in several streams to be woken up just to write one byte and wait >> for the next update. It should even have a higher impact on 1.9+ than on >> 1.8, but nothing alarming in my opinion. We could easily mitigate this by >> waiting for at least a part of the pending data to be refilled before >> waking the streams up. > > So I checked between 1.8 and 2.1-dev today and the result is that we're > not impacted by these issues (checked in code review and tests). I found > that the code was nicely cleaned up between 1.8 and 2.1 because I was > first worried about the apparent missing 0-length check on the headers > frame in 1.9+ then I figured I had already centralized these checks for > safer control :-) > > I ran a few performance tests using some of these types of attacks and > as expected my laptop swallows multi-gigabit/s of such traffic on a > single core. And while looking into this I discovered we had a sub- > optimization of window increment processing which can cause some minor > unfairness between several streams if the window grows in small steps > (typically what can happen if a client sends a connection window update > for each received frame). I found that improving this point resulted in > doubling our capacity to swallow WINDOW_UPDATE frames, jumping from 30 > million frames per second to 65 million per second because we don't try > to make some streams prepare DATA frames if others are already blocked. > So I'm going to merge this into -dev once cleaned up (and don't expect > to backport these since I'm not seeing any real world case where it > matters). > > I also have some slowly ongoing work on a trace mechanism that is still > rudimentary but proved very useful here, that I hope to finish soon, > and that may possibly end up being backported if we find that it speeds > up bug chasing and resolving interoperability issues at a low level. > More on this later. > > Cheers, > Willy >
