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

Oh, excellent point.  I guess that's a reason why we do need the
negotiation at the TLS layer to ensure the next hop knows the protocol and
can strip them out.

On Wed, Oct 22, 2025 at 2:17 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Wed, Oct 22, 2025 at 11:09 AM Erik Nygren <nygren@gmail.com> 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?
>
> Isn't there an interop issue? If I have A->B->C, in a chain, and A
> supports the protocol, and C supports it too, but B doesn't, then we
> have a problem as C will see requests that were supposed to be in
> order potentially intermixed with other things. If we had a space of
> one hop headers that get cleaned out when not supported it would work,
> but AFAIK we don't.
>
> >
> >     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"
>
>
>
> --
> Astra mortemque praestare gradatim
>