On Mon, Oct 16, 2023 at 08:33:51PM +0200, Aleksandar Lazic wrote: > > On 2023-10-16 (Mo.) 20:12, Lukas Tribus wrote: > > On Mon, 16 Oct 2023 at 19:41, Aleksandar Lazic <al-hapr...@none.at> wrote: > > > > > > > > > > > > On 2023-10-16 (Mo.) 19:29, ???? ??????? wrote: > > > > Does 1.8 support http/2? > > > > > > No. > > > > Actually haproxy 1.8 supports H2 (without implementing HTX), as per > > the documentation and announcements: > > > > https://www.mail-archive.com/haproxy@formilux.org/msg28004.html > > http://docs.haproxy.org/1.8/configuration.html#5.1-alpn > > > > > > It does so by downgrading H2 to HTTP/1.1. > > > > > > I don't know whether haproxy 1.8 actually is affected by the rapid > > reset vulnerability or not. I suppose it's possible. > > Well as far as I have understood the attack in a proper way, is the request > in HTTP/2 mode and stay in that Mode, which isn't the case in 1.8. As you > already mentioned was in 1.8 the HTTP/2 request "converted" into HTTP/1 and > 1.9 is the first version which supports end2end HTTP/2.
As Lukas said, in 1.8 H2 is transcoded to HTTP/1.1. It was the very first implementation. The architecture was different (and overly complicated due to the limited abilities by then). Most H2 events would make synchronous calls to the upper layers which would in turn make synchronous calls downwards. The RST_STREAM does call a ->recv() and a ->wake() callbacks. It could be possible that due to this, by chance it was not affected but that would be pure luck, not a design decision. I'll need to run some tests on it to know. Quite frankly, given the numerous limitations of H2 in 1.8, I strongly doubt anyone interested in H2 uses it on 1.8, so if it were to be affected and if a trivial fix couldn't be figured, suggesting to disable it could remain a sane option. Regards, Willy
