- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 15 Jul 2010 13:12:50 +1200
- To: Mark Nottingham <mnot@mnot.net>
- CC: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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 01:14:43 UTC