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

On 10/22/25 18:00, Ben Schwartz wrote:
> From: Erik Nygren <nygren@gmail.com>
> Sent: Wednesday, October 22, 2025 2:06 PM
> 
>> 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.
> 
> I believe simple random number matching is enough to protect against misparsing of the header fields (by terminating the connection if End-Headers is missing or wrong).  It does not protect against misparsing of the request-line, or of the body (presumably due to chunked transfer coding issues?).
> 
> Overall, I think that these "two-ended" approaches are not the right way forward.  Servers that are active and devoted enough to do this work should just enable HTTP/2.
> 
> The interesting question, in my view, is what can be done unilaterally by an intermediary when the next-hop server is potentially vulnerable.  If disabling connection reuse "across the board" is too difficult, another option would be to isolate "risky" requests into separate connections with "Connection: close", while continuing to pool/pipeline "innocuous" requests.  I believe intermediaries could probably identify risky requests pretty reliably with some simple heuristics ("weird" characters and escaping, nontrivial content length, etc.)
> 
> --Ben

What about reserializing the message rather than forwarding it
unchanged?

Many request smuggling attacks that I have seen are due to a
proxy forwarding a message as it was sent, rather than parsing and
reserializing it.  If the proxy always reserializes a message, then
request smuggling is much harder, because the reserialized message
will be unambiguous even if the incoming message was ambiguous.+
That’s why I’m not aware of any smuggling vulnerabilities in which
the frontend server is NGINX, despite NGINX having a very loose parser.
NGINX simply doesn't give the incoming request enough control over
the message sent to the backend.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)