W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: HTTPbis -10 drafts published : Connection header

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 15 Jul 2010 12:25:33 +1000
Message-Id: <9838E785-EE01-465F-83CB-934677111501@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
To: Adrien de Croy <adrien@qbik.com>
Allowing specification of new hop-by-hop headers allows deployment of new connection-oriented features. 

On 15/07/2010, at 11:12 AM, Adrien de Croy <adrien@qbik.com> wrote:

> 
> 
> the client would be affecting the headers in the message forwarded by the proxy to the next hop.
> 
> Actually it makes me query whether it is even necessary to process the Connection header in this way, since all hop-by-hop headers must not be forwarded by intermediaries anyway (they can be re-added if the intermediary understands them).
> 
> All this covers therefore is a client-specified way to specify removal of headers the proxy doesn't recognise as hop-by-hop, which it seems is a bad idea?
> 
> Regards
> 
> Adrien
> 
> On 15/07/2010 12:50 p.m., Mark Nottingham wrote:
>> What kind of exploit? Remember that Connection only affects the headers in *this* message; i.e., in your scenario, the client couldn't affect the response headers.
>> 
>> 
>> 
>> On 15/07/2010, at 10:45 AM, Adrien de Croy wrote:
>> 
>>   
>>> that's quite an interesting scenario
>>> 
>>> if a proxy were to receive a request message with say
>>> 
>>> Connection: content-type
>>> 
>>> in it, what do you think should the proxy do?
>>> 
>>> a) ignore it (not remove Content-Type)
>>> b) reject the message (client attempted exploit)
>>> c) something else
>>> 
>>> it may be clear enough for Content-Type, but what about some other header (e.g. header not known about by the proxy).  Should we have a requirement that a proxy should reject any message that has a token in the Connection header that is not a known hop-by-hop header?
>>> 
>>> regards
>>> 
>>> Adrien
>>> 
>>> 
>>> On 14/07/2010 8:55 p.m., Willy Tarreau wrote:
>>>     
>>>> Hi,
>>>> 
>>>> On Tue, Jul 13, 2010 at 08:18:10AM +0200, Julian Reschke wrote:
>>>> 
>>>>       
>>>>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#appendix-D.11>
>>>>> 
>>>>>         
>>>> Here I have found something that ought to be clarified concerning
>>>> the Connection header :
>>>> 
>>>> 9.1. Connection
>>>>    HTTP/1.1 proxies MUST parse the Connection header field before a
>>>>    message is forwarded and, for each connection-token in this field,
>>>>    remove any header field(s) from the message with the same name as the
>>>>    connection-token.  Connection options are signaled by the presence of
>>>>    a connection-token in the Connection header field, not by any
>>>>    corresponding additional header field(s), since the additional header
>>>>    field may not be sent if there are no parameters associated with that
>>>>    connection option.
>>>> 
>>>>    Message headers listed in the Connection header MUST NOT include end-
>>>>    to-end headers, such as Cache-Control.
>>>> 
>>>> The last sentence is already very important, but some side effects
>>>> remain on some implementations, because it is not stated that only
>>>> headers that were given by the client must be removed. If you take
>>>> Apache 2.2 as a proxy for instance, by default it will add an
>>>> "X-Forwarded-For" header when forwarding the connection to the
>>>> server, to indicate the client's address. If the client says
>>>> "Connection: X-Forwarded-For", then this header is removed from the
>>>> output and the server does not get the client's address. I've not
>>>> checked the code, but I think this is because the header cleaning
>>>> happen just before forwarding the connection, and after header
>>>> addition. This can permit a client to alter the semantics of the
>>>> communication between a proxy and a server, possibly bypassing some
>>>> filtering or hiding its activities. I think that adding a sentence
>>>> such as the following would be fine :
>>>> 
>>>>    If an HTTP/1.1 proxy intends to modify or add headers to the
>>>>    message being forwarded, it may only do so after the headers
>>>>    above have been removed.
>>>> 
>>>> I've also tried to remove "Connection" (which is a hop-by-hop header)
>>>> with Apache and fortunately it did not work. Out of curiosity I tried
>>>> with "Content-Length" and "Host" and they did not work either.
>>>> However, when I try to remove "Transfer-Encoding" (hop-by-hop) on a
>>>> POST with empty body, I observe that "Content-Length: 0" is not added
>>>> to the request, which is harmless (the request will be rejected due
>>>> to missing content length).
>>>> 
>>>> I've just found that other end-to-end headers such as "cache-control",
>>>> "content-encoding" etc... can still be removed via Apache, possibly
>>>> leading to differences in contents interpretation between the proxy
>>>> and the server (eg: when content filtering is performed), though this
>>>> is purely implementation-specific. However, implementation-specific
>>>> differences or limitations sometimes indicate a difficulty in fully
>>>> understanding or respecting a standard.
>>>> 
>>>> Regards,
>>>> Willy
>>>> 
>>>> 
>>>> 
>>>>       
>>>     
>> 
>> --
>> Mark Nottingham     http://www.mnot.net/
>> 
>> 
>>   
Received on Thursday, 15 July 2010 02:25:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT