This is only partially true. The attack exploits a desync between your application and the proxy, so you can vulnerable to this attack even if you are behind a proxy that respects the HTTP spec if your application doesn't. I actually wrote a medium article about this since I fixed the vulnerability in gunicorn [1] a while ago, but I didn't release it (I will and repost here). What you linked to for the AWS ALB is only fixing ONE way to create a desync between the proxy and the server.

EDIT: Here is the link to my blog post https://medium.com/@emilefugulin/http-desync-attacks-with-py...

[1] https://github.com/benoitc/gunicorn/pull/2181

> If you have a different proxy (e.g. some other provider or your own nginx, haproxy before 2.0.6 [2], etc), you might be vulnerable

So I think I'm vulnerable because my setup is nginx->customhttp and my customhttp doesn't understand transfer-encoding-chunked (if there is such a request I just return an error).

As far as I understand this problem only arises if there is both: content-length and transfer-encoding, in which case content-length will be ignored.

Shouldn't this attack be very easily avoided if nginx just discards the content-length-header in such cases? Why should nginx ever send both to the backend?

(I'm assuming here that customhttp means you've got hand-rolled code and isn't somebody's terrible name for their product)

If your customhttp isn't smart enough to handle Chunked encoding it might also just always Connection: Close every request or even just act like an HTTP/0.9 server, in which case it isn't vulnerable.

Request Smuggling requires that both the intermediary (for you nginx) and backend (your customhttp) believe it is possible for one TLS connection to contain multiple HTTP requests, they just disagree on where the boundaries are between those requests.

If either of them insists that no, one TLS connection = one HTTP request, that's legal (but has poor performance which may or may not matter to you) and immunises against Request Smuggling.

By "customhttp" I meant my hand-rolled (subset of)http-server. It doesn't support chunked encoding because I also control the client-code but it does support "connection keep-alive" for better performance.

I haven't testet it yet but I'm pretty sure its vulnerable: my server just looks for content-length and if it doesn't find it, it returns an error. So if nginx sends content-length but then continues to send chunked content it should be possible that the next request won't come from nginx but from an attacker (probably not really a problem at the time but nevertheless not the expected behaviour).

My failure was to always expect "valid" HTTP-input from nginx whereas "valid" means my limited knowledge of HTTP.

But the question remains: Is there a reason why nginx should send both headers to the backend?

If you don't implement an encoding you should obey the HTTP/1.1 standard and "return 501 (Unimplemented), and close the connection". In your case even though not implementing chunked encoding is prohibited, this drop through would save you.

Valid means what the standard says it means. What you don't know can hurt you.

However, if modifying your backend code is hard, you can apparently tell nginx that you don't do chunked encoding and it will sort out the 501 on your behalf. I have not tried this and YMMV.

I completly agree and I'm sure nginx is doing it right by following the specification but isn't this a bug in the specification? Why should there be a content-length but then a chunked body.

And if this is a bug in the specification, shouldn't nginx fix it to help us backend-fools?

Allowing Connections to your backend directly might make you vulnerable to certain types of attack but it doesn't impact Request Smuggling.

The trick in Request Smuggling is that you're trusting an intermediary (in this case a frontend reverse proxy) to mingle everybody's requests into a single pile for you to process and they don't agree with you about how to do this. Chuck thus gets to submit a request which is mingled with Alice's and you end up letting Chuck modify Alice's request. Oops.

But Chuck sending requests directly to your backend doesn't allow him to do this. You're definitely not going to think Chuck's weird garbled nonsense is part of Alice's request when it isn't even on the same TLS connection.

Also keep in mind that if you use IP-based whitelisting, an attacker can register their own CF/Fastly account and target your origin server with whatever CDN settings they want (assuming they can discover your origin server). With Fastly at least you can even do this from the free tier.

Took me a second to wrap my head around what you were saying, so I'll point it out: they'd be pointing their CDN account to your origin server, and making requests through it.

Same for Cloudflare - to mitigate this your server should only respond to the correct HOST header for your website.