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

Thanks for the feedback.

This is a good point on the hash and may feed into the threat model.  I
fear that for some uses (eg, things blurring into the FIPS world) it
becomes hard to use lighter hashes without a clear understanding for how
they are not exploitable it an attacker ever gets one of the
headers replayed back to them.  But this may feed into potentially needing
crypto-agility and the ability to negotiate which MAC function to employ.
The negotiation likely needs to happen at the same time as the key exchange
(eg, during the TLS handshake).

On what the signature/MAC covers, I think this is a good point and one that
needs discussion if this work is picked up.
At one end of the spectrum all we may need is something covering the
request serial -- that helps for a class of the "next request" model.
Although an idea like Ben suggests in another mail here on including this
binding in a "Begin-Headers" and "End-Headers" that are
at the start and end might be another approach which could help with lines
blurring between requests where the serial on its own might not help.
At the other end, we'd sign the URI components and all the headers (perhaps
with some ability to annotate provenance for specific headers
as to whether it comes from the endpoint or a previous hop).  If this gets
too complex then the effort of implementation will get too big as a patch
relative to switching to H/2.  If it's not complete enough then it won't
defend against enough to be worthwhile.

Thanks, Erik


On Wed, Oct 22, 2025 at 1:30 AM Willy Tarreau <w@1wt.eu> wrote:

> Hello Erik,
>
> On Sun, Oct 19, 2025 at 12:18:02PM -0400, Erik Nygren wrote:
> > I've submitted a new -00 draft
> > for draft-nygren-httpbis-http11-request-binding:
> >
> >    HTTP/1.1 Message Binding adds new hop-by-hop header fields that are
> >    cryptographically bound to requests and responses.  The keys used are
> >    negotiated out-of-band from the HTTP datastream (such as via TLS
> >    Exporters).  These header fields allow endpoints to detect and
> >    mitigate desynchronization attacks, such as HTTP Request Smuggling,
> >    that exist due to datastream handling differences.
> (...)
> > I'm looking forward to discussing this in Montreal in two weeks to see if
> > this is something that other implementers (especially of Intermediaries
> and
> > Origin Servers) would be  interested in.  I'd also be thrilled to add in
> > one or more co-authors as this adds the most value if it is implemented
> and
> > deployed by as many vendors and open source projects as possible.
>
> I'm seeing a few points of concern in this first draft. The first
> one is the use of hmac(sha256) which seems overkill to me. A quick
> test shows that it would increase CPU computation by up to 20%
> compared to the cost of parsing and processing an HTTP request, and
> I think we don't need something that heavy here since an attacker's
> capabilities when trying to exploit smuggling remain limited. I.e.
> even something as light as XXH3 would be awesome with a much lighter
> cost.
>
> The second point is that the signature covers the method and the
> authority (or host). However this will not protect against all
> types of smuggling, because often the method doesn't need to change,
> and the host remains the same. Sometimes only a few unterminated
> header fields can be prepended in front of a request, leaving the
> request line appear as part of a dummy header. Or conversely, it is
> possible to "eat" a part of the next request, requiring the attacker
> to place their new request line in a dummy header, but letting the
> intermediary append other ones after. Generally, only the URI
> changes between the two sides of an intermediary that is under
> attack, whose goal is to bypass filtering. As such I'd suggest that
> instead the hash should cover the method, the host header field, and
> the URI as it is sent (no need to perform some particular operations
> to isolate the path from the authority, let's just sign what is sent).
> I think this would be much more robust and even simpler to implement.
>
> Just my two cents,
> Willy
>