]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MEDIUM: h1: allow to preserve keep-alive on T-E + C-L
authorWilly Tarreau <w@1wt.eu>
Fri, 26 Jul 2024 13:14:58 +0000 (15:14 +0200)
committerWilly Tarreau <w@1wt.eu>
Fri, 26 Jul 2024 13:59:35 +0000 (15:59 +0200)
commit2dab1ba84b11fe43baa91642ffcddb90e9ec09d2
tree6e2ceccf6f6003a72aeec673e38c957728d09a46
parent85131f91bf726039acf49c6fe5333df0a6aaa959
MEDIUM: h1: allow to preserve keep-alive on T-E + C-L

In 2.5-dev9, commit 631c7e866 ("MEDIUM: h1: Force close mode for invalid
uses of T-E header") enforced a recently arrived new security rule in the
HTTP specification aiming at preventing a class of content-smuggling
attacks involving HTTP/1.0 agents. It consists in handling the very rare
T-E + C-L requests or responses in close mode.

It happens it does have an impact of a rare few and very old clients
(probably running insecure TLS stacks by the way) that continue to send
both with their POST requests. The impact is that for each and every
request they'll have to reconnect, possibly negotiating a full TLS
handshake that becomes harmful to the machine in terms of CPU computation.

This commit adds a new option "h1-do-not-close-on-insecure-transfer-encoding"
that does exactly what it says, it just asks not to close on such messages,
even though the message continues to be sanitized and C-L dropped. It means
that the risk is only between the sender and haproxy, which is limited, and
might be the only acceptable solution for such environments having to deal
with broken implementations.

The cases are so rare that it should not need to be backported, or in the
worst case, to the latest LTS if there is any demand.
doc/configuration.txt
include/haproxy/h1.h
src/h1.c
src/mux_h1.c