W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: I-D draft-petersson-forwarded-for-00.txt

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 8 Apr 2011 17:36:31 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Andreas Petersson <andreas@sbin.se>, Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, Karl Dubost <karld@opera.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20110408153631.GD13348@1wt.eu>
On Fri, Apr 08, 2011 at 02:08:09PM +0000, Poul-Henning Kamp wrote:
> In message <20110408153603.6e3f7e2b@hetzer>, Andreas Petersson writes:
> >What do the list think?
> >What parameters would be relevant? ("by"? "port"? "proto"? "host"?
> >other..?)
> I've pondered this some more, and I fear we are headed the wrong way.
> This header, like X-Forwarded-For will become part of the toolbox
> for answering criminal investigations log-requests and similar and
> we must think about it in that light.
> Spoofing X-F-F headers have been used in the past, both to circumvent
> badly thought out security-barriers and generally confuse people
> reading logfiles.
> The IP#'s you receive in such headers from the outside, are only
> badly hashed cryptographic nonces:  You don't need to sit in the
> White House to send an (X-)F-F with IP#
> Nothing is actually won by mandating that they look like IP# in the
> first place, but it is very convenient for well-behaved-net-entities
> that they are IP#, and this probably covers 99.99% of the cases
> where somebody has to deal with them.
> So my considered proposal would be:
> The standard should make this header as a comma separated list of
> identifiers defined like:
> 	1*<any CHAR except LWS and ",">
> The standard should make it very clear that they are nonces which
> can only be correctly interpreted in the context where they were
> created.  (In other words:  A lawyer cannot sue based on the
> identifier, until whoever created it translates its meaning for him,
> even if it looks like an IP number).
> And then we SHOULD strongly encourage that they follow this form:
> 	src-IP ':' src-port [ '/' dst-IP ':' dst-port ]

While I agree with the principle, I would render the port optional.
It's almost always wrong anyway because you have the equipments in
the following order :

   load balancer

The load balancer almost always translates the source port (unless it's
doing DSR, which is progressively disappearing), and nobody car correlate
this source port seen by the reverse-proxy to anything logged anywhere.
So while there are *some* situations where the port can be exploited, i
practice where admins do care about logs, it's meaningless.

Received on Friday, 8 April 2011 15:37:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:46 UTC