Harden against HTTP Desync attacks

[Sytten]

Problem
HTTP Desync attacks are pretty bad and there are a lot of bad/permissive http implementations out there that act as proxies.
I didn't see any discussion / tests of hyper surrounding that so I wanted to start the discussion around the topic given that hyper is now 1.0 (and used in production in a lot of places).

Ideas

• A suite of tests to demonstrate that an hyper server reacts as best it can (given it doesn't control the proxy)
• Creating a flag for hardened/more strict version of hyper (server mostly)

For the second point, I would take a lot of work that has been done by AWS already in https://github.com/aws/http-desync-guardian and try to incorporate it in hyper where it makes sense. This includes going more strict than the spec to avoid confusions.

Things like ignoring a CL when a TE is present is risky (even if the spec says that it must be ignored) since a proxy might very well not ignore the CL. So even if hyper is "correct", that won't prevent a leak. Under an hypothetical strict flag, this would result in the request being rejected.

hyper/src/proto/h1/role.rs

Lines 251 to 253 in 210bfaa

	if is_te {
	continue;
	}

Additional context

• https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
• https://portswigger.net/research/http2

[seanmonstar]

Thanks for the suggestion! I agree with the premise, for sure! I have mentioned in other issues the idea of having a "strict" option. (I kinda wonder if it would eventually need to be made multiple options, as people want some strict things but not others.) Another point I think is to consider whether these things need to live in hyper itself, or if it can be part of recommended middleware.

More tests is always welcome, too!

[Sytten]

Most checks can probably live in middlewares but desync attack operate on the write buffer of the connection to leak data of other users when the proxy reuses the same connection. So I think this would need to live in hyper. Regarding the multiple flags I do agree, maybe similar to the desync attack prevention modes provided by AWS for the ALB?

[Sytten]

I do want to comment back @seanmonstar since a new set of techniques just dropped at defcon. You can check https://portswigger.net/research/http1-must-die. Especially the 0.CL with Expect header. Cloudflare Pingora was impacted (https://blog.cloudflare.com/resolving-a-request-smuggling-vulnerability-in-pingora/).

[seanmonstar]

Yea, I've seen the whitepaper. Interesting stuff, but hyper is fine. We strive for stricter parsing, and the message-length code handles all the steps outlined in RFC 9112 SS 6.4.

At some point Pingora decided to re-implement http1 in-tree 🤷 hyper is not vulnerable to that one.

(I'm actually going to close this, it's a bit too general. I'm trying to keep issues open that are either tracking several steps of work, or have a very specific bug/feature. Other things can be discussions, blog posts, or other libraries.)

[Sytten]

@seanmonstar make sense to close the issue, could you move it to a discussion instead? That way we keep the context for others that might want to comment.