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

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?

    Erik




On Wed, Oct 22, 2025 at 1:44 PM Ben Schwartz <bemasc@meta.com> wrote:

>
>
> ------------------------------
> *From:* Erik Nygren <nygren@gmail.com>
> *Sent:* Wednesday, October 22, 2025 11:34 AM
>
> >> D. Define new header fields to demarcate the header section (e.g.
> "Begin-Headers: (unpredictable value) ... End-Headers: (same value)").
> This could be extended to cross-check the header in various ways (e.g.
> enumerating the payload length of each header field).
>
> ...
>
> > It's also possible that with that we could switch from
> HMAC-SHA256(key,serial) to something like a keyed PRNG then?
>
> Yes, but I was thinking of just using /dev/urandom.
>
> > For example, don't make the serial explicit but instead have it implicit
> and use:
>
> > Begin-Headers: Crypto-PRNG(key, serial*2)
> > End-Headers: Crypto-PRNG(key, serial*2+1)
>
> Why do they need to be different?  Is there a way for the attacker to see
> the Begin-Headers field?
>
> > In that case it might also be ok to include some additional unprotected
> but carefully encoded information on the Begin-Headers line?
>
> Yes, or on End-Headers:
>
> GET /example HTTP/1.1
> Begin-Headers: 3141592
> Host: example.com
> X-Evil-Header: "value\r\nContent-Length:0\r\n\r\nPOST /..."
> Content-Length: 100
> End-Headers: 3141592, lengths="11,1234,3"
>