Re: HTTP/1.1 Request Smuggling Defense using Cryptographic Message Binding (new draft)

[Willy Tarreau <[e-mail]>]

On Wed, Oct 22, 2025 at 02:06:06PM -0400, Erik Nygren wrote:
> Unassociated random numbers alone won't help enough with request
> desynchronization.  An attacker wanting to do something could just add
> their own within a body to create a new request and get things
> desynchronized.
> 
> It might be worth thinking about if we can ditch negotiation though and
> just use Begin-Headers on the first request on a persistent connection
> to initialize things, where the number there is then incremented each time
> by cranking a PRNG seeded off the first value in request?

Please keep in mind that you're trying to close an ultra-rare tiny gap
that temporarily affects some implementations. We don't need the level
of security that one would need to secure data circulating in clear over
a hostile channel, here we're speaking about stacks that have been proven
for a long time and that are trying to slightly improve their safety by
saying "if someone would manage to find a new smuggling attack we'd be
more robust". But the purpose of that code is to never ever trigger the
failure path. So it is important that this remains really inexpensive
to have any chance to convince anyone to actually implement it.

Also, with the begin-headers/end-headers, we cannot cover the request
line, and smuggling definitely happens there (e.g. by inserting spaces
in the method over H2/H3). IMHO we could reasonably imagine to hash
the request line and mix it with a secret and a request counter over
the connection, that is repeated both in begin-headers and end-headers.
This would validate that the request line is intact and that the headers
remain associated to that request. I'd even say that if we do this we
don't need the begin-headers anymore, the end is sufficient since the
request line is validated. And really, let's make sure the hash is
ultra-cheap. We don't need something cryptographically secure here,
so much more energy is spent trying to even find a vulnerable
implementation that a very fast non-cryptographically secure hash will
divide the probabilty enough that it will be sufficient to deter any
attempt.

Willy