[squid-users] What squid should do with RFC non-compliant response header?

[Amos Jeffries]

On 6/04/2017 7:32 a.m., Eliezer  Croitoru wrote:
> Thanks for the reponse.
> Actually browsers ignore the header as a response header and do not show it at all.
> (at least firefox)
> Technically I would expect squid to pass it but it's might have the potential for a CVE in some casese.
> 

There is actually a CVE problem "HTTP request/response smuggling" in all
cases of the type you described.

I dont know why you are asking for votes or opinions on this. Once the
message formatting has been violated there is exactly zero ways for
software to tell where that broken header ends. What any particular
person expects does not enter into it. Zero is zero.


All the rest of the bytes received from the sender may be part of that
single broken header.  That includes the ':' that you *assumed* was end
of header name, and CRLF bytes which would in real HTTP syntax normally
signify end of header and/or end of message. The header is not HTTP
syntax, therefore HTTP syntax no longer applies and the CRLF plus other
lines that look on the surface like HTTP syntax could all be part of its
middle.
 Thus the smuggling CVE applies to all cases where the headers are
invalid at the syntax/format level.

There are exactly two things that can be done by a proxy when this type
of error is encountered:

 1) what the RFC says to do (and should be expected from any HTTP proxy)
- deliver the client a 4xx for broken requests or 5xx for broken
responses. Terminating the connection when the error is sent.

or
  2) truncate the message at the CRLF before the garbage and drop all
other bytes received on that connection. Terminate the connection when
the HTTP transaction is "completed".


Doing (2) might sound attractive in terms of getting something to the
user at any cost. But what the user actually sees is a range of bad
behaviour from incomplete web pages, to broken web applications, to
plain wrong responses coming back. With no indication of what is going
wrong.
 To give a clear idea of what is broken and where the problems is - the
best option for a proxy is (1). To do the same thing as a browser is
just creating harm.


FYI: The HTTP RFCs are based squarely in running code implementations
with decades of testing behind them now. Going against what is written
there is exactly the best way to cause yourself (and users) trouble and
pain when interacting with other HTTP software.

Amos