httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: 2.1.5 available for testing
Date Thu, 23 Jun 2005 13:20:52 GMT
Jeff Trawick wrote:
> On 6/23/05, jean-frederic clere <jfrederic.clere@fujitsu-siemens.com> wrote:
> 
>>William A. Rowe, Jr. wrote:
>>
>>>++1 To Joe's comments.
>>>
>>>Jeff's fix is technically right, but scares the nibbles out
>>>of me.  If, for example, an exploit is able to inject the
>>>T-E on top of the legit C-L, I really suspect we should not
>>>trust the origin server at all.
> 
> 
> One important situation to fear is a buggy server or proxy+server that
> we may not be able to talk to at all if we are extremely strict.
> 
> [As you implied w.r.t. Apache 1.3] The smuggling fear is really if we
> allow keepalive on this connection to the origin server again.  We
> could be confused by making the wrong choice from {CL, TE} and
> misunderstand the next response.  We can set backend->close and
> origin->keepalive to prevent that.
> 
> If we don't allow keepalive, then it is down to whether or not this
> single request can be parsed correctly if our choice of {CL, TE} makes
> sense.
> 
> 
>>>For origin servers (as opposed to clients) make this choice
>>>between ignore C-L, or fail, configurable?
> 
> 
> try very hard to make a reasonable choice with no configuration :) 
> (speaking to the choir, of course)
> 
> 
>>>My observation is that there are far more varied clients in
>>>the world than servers, each with unique faults.  But the
>>>RFC 2616 is clear...
>>>
>>>   Messages MUST NOT include both a Content-Length header field and a
>>>   non-identity transfer-coding. If the message does include a non-
>>>   identity transfer-coding, the Content-Length MUST be ignored.
>>>
>>>   When a Content-Length is given in a message where a message-body is
>>>   allowed, its field value MUST exactly match the number of OCTETs in
>>>   the message-body. HTTP/1.1 user agents MUST notify the user when an
>>>   invalid length is received and detected.
>>>
>>>...and server authors can be expected to be less buggy than clients.
>>>"Permissive in what we accept, strict in what we send" implies some
>>>strictness in what we trust to pass on to the client.
> 
> 
> We're removing the protocol breakage in what we pass on to the client.
>  At this point, we either send a valid response or it is if the server
> dropped the connection before sending the full response.
> 
> (I hear what you're screaming.  I think the minimal-intervention path
> should be preferred if we can justify it.)
> 
> 
>>>So +.5 to Jeff's patch, and let's discuss if the proxy response should
>>>then be trusted at all with T-E and C-L, in httpd-2.x where we support
>>>keepalives.
>>
>>Once the patch applied we lose the information that the request was "incorrect".
>>That means we won't be able to choose in proxy between sending C-L (and dechunk)
>>and T-E.
> 
> 
> I don't follow here.  How does the backend choice of {TE, CL} affect
> what we send the client?
> 
> 

If we are acting as a proxy, what we send to the next proxy is changed by the 
patch, isn't it?

Mime
View raw message