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

Ben,

> On Oct 22, 2025, at 10:54 AM, Ben Schwartz <bemasc@meta.com> wrote:
> 
> I think this draft identifies a real problem, but I'm not convinced that this is the right solution.
> 
> As a defense against request smuggling, this header is only a partial defense:
> 1.Both parties must upgrade their software to benefit.  This is a particularly serious limitation because the relevant parties are specifically those with limited ability to upgrade their software (otherwise they would be using HTTP/2).

I'm not sure I'd agree with that assertion.  HTTP/2 (and HTTP/3) add a lot of complexity to support multiple parallel requests/streams (as is common for web pages/sites) while HTTP-based protocols typically only need the single request/stream model supported by HTTP/1.1.

> ...
> There are many other strategies that we could explore that would be easier to deploy and/or more effective.
> 
> A. Declare a limitation on the reuse of HTTP/1.1 connections, similar to draft-ietf-httpbis-optimistic-upgrade.  For example, this might say "when speaking to a potentially vulnerable server, an intermediary MUST NOT reuse a single HTTP/1.1 connection for requests from multiple clients (unless they are mutually trusting)".  This reduces efficiency, but anyone who cares about efficiency shouldn't be using HTTP/1.1.

WRT efficiency it depends on what you are doing - HTTP/2 brings its own overhead and complexity.

I think the security considerations of using (shared) proxies are more relevant for *any* version of HTTP.

> B. Confirm the HTTP/1.1 parser state between requests.  For example, an intermediary could inject a request like "TRACE /.well-known/barrier/$random HTTP/1.1" after each forwarded request, and check that the TRACE response is received correctly before forwarding the next request.

Assuming that TRACE is supported end-to-end of course.

> C. Document a simple profile of HTTP/2 (e.g. SETTINGS_HEADER_TABLE_SIZE=0, SETTINGS_MAX_CONCURRENT_STREAMS=1, etc.)

I actually tried something like that when I initially prototyped IPP (RFC 8010/8011 aka STD 92) on top of HTTP/2 (geez it's been almost 10 years), but experienced problems with HTTP/2 proxies...  Perhaps those issues are resolved now, but without header compression and multiple stream support, the only remaining advantage over HTTP/1.1 is keeping a connection alive after errors, so why bother adopting/implementing HTTP/2?

________________________
Michael Sweet

Received on Thursday, 23 October 2025 14:03:36 UTC