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

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

Received on Wednesday, 22 October 2025 05:30:45 UTC