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

On 10/19/25 12:18, 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.
> 
> While it would be great if the entire world could switch to HTTP/2 and
> HTTP/3,
> that just isn't feasible as there are legacy HTTP/1.1 clients that need to
> be supported, as well as a large ecosystem of HTTP/1.1 Intermediaries and
> Origin Servers.
> 
> This proposal provides a hop-by-hop defense mechanism that allows endpoints
> to defend HTTP/1.1 traffic against Request Smuggling attacks without
> fundamentally changing the HTTP/1.1 protocol, and in a way which can
> hopefully drop-in to auto-negotiate and "just work" to provide
> defenses.  There are still quite a few different directions we could take
> the design, as discussed briefly in the draft, as well as some open issues
> around how particular details get implemented.
> 
> Note that this is focused on H1.  While H2 and H3 have streamids and other
> ways to convey information out-of-band, H1 lacks those.  You can see this
> as a way of getting stream ID equivalents into H1 in a protected but
> minimally invasive manner.
> 
> 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.
> 
> Best, Erik

I wonder if it would make sense to provide an HTTP conformance test suite
to ensure that all H1, H2, and H3 implementations parse messages the same
way.  This could cover all known smuggling vectors and be extended whenever
a new one is encountered.  In particular, it would catch things like:

- Accepting invalid chunk extensions (probably many implementations).
- Accepting chunk lines that end with LF instead of just CRLF (NGINX,
  HAProxy).
- Accepting headers that are specified in the HTTP standard but are
  syntactically incorrect.  This is especially true for anything
  involving framing.  (Many implementations)
- Accepting NUL bytes or control characters where they aren't allowed
  (NGINX).
- Accepting both Transfer-Encoding and Content-Length (many vulns).
- Accepting distinct Content-Length headers (libsoup, old lighttpd).
- Accepting trailers that are not allowed (NGINX).
- Accepting malformed trailers (NGINX).
- Accepting headers with no colon (NGINX).
- Mishandling leading and trailing tabs in field values (NGINX).
- Mishandling bodies in GET requests (old Pingora).
- Mishandling headers longer than 255 bytes (old HAProxy).
- Mishandling headers with uncommon cases (some old webservers).

Some of these are H1 specific, but many are not.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)