[Varnish] #1729: Incorrect parsing of responses containing both chunked transfer-encoding and Content-length

[Varnish]

#1729: Incorrect parsing of responses containing both chunked transfer-encoding
and Content-length
----------------------+----------------------
 Reporter:  regilero  |       Type:  defect
   Status:  new       |   Priority:  normal
Milestone:            |  Component:  varnishd
  Version:  4.0.3     |   Severity:  normal
 Keywords:            |
----------------------+----------------------
 RFC 7230:
 > A sender MUST NOT send a Content-Length header field in any message
 >   that contains a Transfer-Encoding header field.
 > (...)

 So having a backend response with both headers is an issue on the backend
 side.
 It means this is not a security issue for varnish.

 But when it happens:
 RFC 7230:
 > If a message is received with both a Transfer-Encoding and a
 > Content-Length header field, the Transfer-Encoding overrides the
 > Content-Length.  Such a message might indicate an attempt to
 > perform request smuggling (Section 9.5) or response splitting
 > (Section 9.4) and ought to be handled as an error.  A sender MUST
 > remove the received Content-Length field prior to forwarding such
 > a message downstream.

 In varnish 4.0.3, maybe because of #1506 and https://www.varnish-
 cache.org/trac/changeset/535d44b8909ee88e8700a35bed79f9ca77e445a4 the
 Content-length header from the response is not rewritten, it is assumed to
 be exact.

 The transfer-encoding: chunked is removed, so sending a content-length
 header is right.

 The chunked body is de-chunked (so varnish knows the real Content-length),
 and added in the new de-chunked response body without altering the initial
 Content-Length header.

 If this content length is wrong, the de-chunked content could contain a
 second http response (http smuggling).

 Expected behavior:
 -------------------

 Either:
  * close the connection in error in case of conflict between the observed
 Content-Length and the original Content-Length
  * or fix the Content-length header if the length is known
  * or reject backend responses containing both chunked Transfer-Encoding
 and Content-Length

 There may be other problems with streamed responses, where chunks are
 transferred as they come (not sure this is supported in varnish).
  * if the Content-length header is not rejected, received chunks size
 should not exceed the initial content-length (and then close client
 connection if it happens)
  * prevent content-length header in chunk trailers (do not forward it)

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1729>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator