tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Riggs <>
Subject Re: RemoteIpValve advices
Date Fri, 04 Feb 2011 19:46:49 GMT
On Jan 31, 2011, at 3:57 PM, Mark Thomas wrote:

> On 31/01/2011 21:54, Henri Gomez wrote:
>>> Not necessarily.  The closest immediate proxy is the last entry in that
>>> list.  You might not trust all of the machines in that proxy chain to provide
>>> legitimate IP details.
>> In my case, x-forwarded-for:,, was my
>> browser IP and EC2 IP.
>> the Valve is not activated by default and should only be used in
>> Amazon Load Balancing case.
>>> mod_remoteip has the concept of trusted vs. untrusted proxies, where only the
>>> trusted ones will be allowed to present the next-immediate-left IP address as
>>> a legitimate proxy address, and that IP is then compared to the trust list.
>>> So you might trust yahoo or google's proxy servers, but not your typically
>>> pwned user PC which is relaying spam or being employed as a DDoS agent.
>> x-forwarded-server: domU-12-31-38-00-B2-08.compute-1.internal is a
>> trusted server, aka EC2 box.
>> So +1 to have this on RemoteIpFilter/Valve, an uniq filter/valve to
>> handle such cases.
>> Mark to you need code contribution on RemoteIp Valve ?
> Patches to RemoteIpFilter/Valve are the place to start. The issue of
> trusted proxies are already handled so the patches should be able to
> take advantage of that.

I'm a bit slow catching up and picking up on this thread, but I want to make sure that we
are very careful with who we trust and what we do with regards to the X-Forwarded-* headers.
 As they are just ad-hoc (non-)standards, there is very different behavior out there in the
wild WRT proxies.  In general (at least in my experience), the only header that is fairly
well supported is X-Forwarded-For.  All of the others are a crapshoot.

For example, say that a request goes through 3 proxies, A, B, and C.  If they all behave relatively
well, we will get an `X-Forwarded-For: A, B, C'.  We trust B and C, so we will get a remote
IP of A in TC.  Now, we also get `X-Forwarded-Proto: https', `X-Forwarded-Host: foo', etc.
Now where did these come from?  I have personally never seen a proxy that will append comma-separated
values to any of these other headers (e.g. `X-Forwarded-Proto: https, http, http'), and even
if they did, they could easily be forged.  If anything is done with these, you had better
be certain -- without a shadow of a doubt -- that these values can be trusted.  That is, if
you are only getting a single value for X-Forwarded-(Port|Proto|Host|Server|...), you need
to be sure it was set by your last trusted proxy.

What does this mean from a TC perspective?  Without an official standard for X-Forwarded-*,
we need to be cautious about what we do with these headers.  Even the handling we currently
do with X-Forwarded-Proto and setting the port and scheme is dubious.  Having the options
to handle additional headers is good, but they should have to be explicitly enabled.

As for me, one of the first things I do when traffic hits my perimeter boxes is to strip off
all X-Forwarded-* headers.  That way when I use them internally, I know they can be trusted.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message