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

Thanks for the feedback.  I intended this as an initial stake-in-the-ground
for starting discussion, and to demonstrate
one possible approach that would help substantially.  It is worth exploring
other options as you suggest.

>  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 think this is true of all mitigations here, so a goal is to find
something minimally invasive and ideally that works as a drop-in that can
negotiate during TLS connection establishment.

> 2. Not all known parser confusion attacks are prevented, as noted by
others in this thread.

Agreed -- it's going to be a balance of finding how much we can defend
against without making the implementation cost so high that it becomes
undeployable.

> 3. It's not clear how to use it without TLS.  TLS may not be in use when
the intermediary and backend are inside a single deployment (or even a
single host!).

I think we need something that auto-negotiates and "just works" when TLS is
in-use (eg, TLS Exporters do that).
When TLS isn't in-use, the parties involved hopefully (or had better!) have
some OOB way of ensuring there is adequate trust.
How these work tend to be proprietary, such as the haproxy PROXY Protocol
preface which could also include keying/config information.

Some initial thoughts on these:

> 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.

Unfortunately the perf hit of this is way too high over the network.  Even
with TCP Fast Open and 0RTT (which have their own issues) anything over the
WAN really needs Persistent Connections.

> 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.

This is an interesting idea as a barrier and could help, but I'd worry that
by adding an RTT and/or preventing pipelining it might slow things down too
much to be deployable.

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

While worth doing for other reasons, I fear this will be too invasive to be
deployable.
(eg, ideally some mitigation here is of the scope that it could get a
drop-in POC implemented in a hackathon.)

> 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).

I like this idea.  I'm not sure that just doing this without having the
value bound into the connection state is going to be good enough and this
won't defend against all attacks, but doing something like moving my
Bound-Headers to the start of the headers and then having a
Bound-Headers-End at the end of the headers might defend against a class of
these attacks and might remove the need to include anything other than the
serial.

It's also possible that with that we could switch from
HMAC-SHA256(key,serial) to something like a keyed PRNG then?
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)

(where key is the seed and second argument is how many times to crank the
prng).
In that case it might also be ok to include some additional unprotected but
carefully encoded information on the Begin-Headers line?

        Erik



On Wed, 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).
> 2. Not all known parser confusion attacks are prevented, as noted by
> others in this thread.
> 3. It's not clear how to use it without TLS.  TLS may not be in use when
> the intermediary and backend are inside a single deployment (or even a
> single host!).
>
> 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.
> 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.
> C. Document a simple profile of HTTP/2 (e.g. SETTINGS_HEADER_TABLE_SIZE=0,
> SETTINGS_MAX_CONCURRENT_STREAMS=1, etc.)
> 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).
>
> --Ben
> ------------------------------
> *From:* Erik Nygren <nygren@gmail.com>
> *Sent:* Sunday, October 19, 2025 12:18 PM
> *To:* ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
> *Subject:* HTTP/1.1 Request Smuggling Defense using Cryptographic Message
> Binding (new draft)
>
> 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
> 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
>
>
>
> [try #3 at sending to the list, this time with a different email address]
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Thu, Oct 16, 2025 at 6:23 PM
> Subject: New Version Notification for
> draft-nygren-httpbis-http11-request-binding-00.txt
> To: Erik Nygren <erik+ietf@nygren.org>, Mike Bishop <mbishop@evequefou.be>
>
>
> A new version of Internet-Draft
> draft-nygren-httpbis-http11-request-binding-00.txt has been successfully
> submitted by Erik Nygren and posted to the
> IETF repository.
>
> Name:     draft-nygren-httpbis-http11-request-binding
> Revision: 00
> Title:    HTTP/1.1 Request Smuggling Defense using Cryptographic Message
> Binding
> Date:     2025-10-16
> Group:    Individual Submission
> Pages:    15
> URL:
> https://www.ietf.org/archive/id/draft-nygren-httpbis-http11-request-binding-00.txt
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-nygren-httpbis-http11-request-binding-00.txt__;!!Bt8RZUm9aw!8SW65kTV1j3ovn8oF_js6jwwvkxl31JLh6vH6kmcUorclI41OwJdNsYowFHAiPBvIG1aG2VFgQ$>
> Status:
> https://datatracker.ietf.org/doc/draft-nygren-httpbis-http11-request-binding/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-nygren-httpbis-http11-request-binding/__;!!Bt8RZUm9aw!8SW65kTV1j3ovn8oF_js6jwwvkxl31JLh6vH6kmcUorclI41OwJdNsYowFHAiPBvIG3w31jcQg$>
> HTML:
> https://www.ietf.org/archive/id/draft-nygren-httpbis-http11-request-binding-00.html
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-nygren-httpbis-http11-request-binding-00.html__;!!Bt8RZUm9aw!8SW65kTV1j3ovn8oF_js6jwwvkxl31JLh6vH6kmcUorclI41OwJdNsYowFHAiPBvIG1hZKWG5g$>
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-nygren-httpbis-http11-request-binding
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-nygren-httpbis-http11-request-binding__;!!Bt8RZUm9aw!8SW65kTV1j3ovn8oF_js6jwwvkxl31JLh6vH6kmcUorclI41OwJdNsYowFHAiPBvIG0_87c3XA$>
>
>
> Abstract:
>
>    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.
>
>
>
> The IETF Secretariat
>
>