4 ms·

> 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

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

tialaramex 7y ago
(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.
- jackewiehose 7y ago
  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?
  - tialaramex 7y ago
    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.
    - jackewiehose 7y ago
      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?

tialaramex 7y ago

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

jackewiehose 7y ago
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?
- tialaramex 7y ago
  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.
  - jackewiehose 7y ago
    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?