httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: mod_remoteip
Date Sat, 14 Dec 2013 01:03:07 GMT
> There is nothing I see in the code that prevents a cycle with internal
proxy from following a cycle with external proxy.

It's been several years so I was going from memory, but you are right...

> So if your explanation is the way the code is intended, there may exist
some subtle  error cases.

Yes, the 'fail case' illustrated simply prevented the trusted proxy from
presenting a private address.

I think this is an error, that it should have further prevented a a trusted
proxy from returning to the
internal proxy list, and patches are welcome.

There's one other enhancement I've wanted to make, to accept an trust as
internal another
RemoteIPInternalHeader value from any routing appliances.
 Said appliance would be responsible
for dropping any incoming value from the client, and replacing it with an
absolute header or list
of headers.  Typical routing solutions use X-Remote-IP or similar headers
to convey this info.

So the processing order would be the values in the RemoteIPInternalHeader
list, followed by
the RemoteIPHeader values matching the
and then restricted to
extranet addresses presented by the

But in enforcing this change, some configurations are likely to be broken
where users have an
assorted collection of Internal and Trusted Proxy members which don't
actually follow this
design, so we might be a bit late in changing this before 2.6.

On Fri, Dec 13, 2013 at 6:26 PM, Mike Rumph <> wrote:

> On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote:
>> On Mon, 09 Dec 2013 11:10:46 -0800
>> Mike Rumph <> wrote:
>>  As you can see from the bug report, I have been looking into this.
>>> It might also be important to  consider the related bug 55637:
>>> -
>> Closed invalid.  The incorrect assumptions are very similar to but
>> distinct from the 55635 case.
>> In this case, let's use a car's title as it's internal proxy document
>> and the car's ignition keys as the trusted proxy document.  Although
>> you might trust one with your car keys, they can go ahead and share
>> those keys with yet another party.  We would not want to design the
>> remoteip logic to then let that individual hand another party the title
>> to the vehicle :)  Once the InternalProxy list is exhausted and we have
>> begun processing the TrustedProxy list, we can never again assign the
>> next apparent proxy to be an InternalProxy.  That would be a claim by
>> an external party whom we can't assign that much trust to.
> So I think you are referring to the difference between
> RemoteIPInternalProxy and RemoteIPTrustedProxy, correct?
> Your explanation sounds reasonable, but to me it doesn't appear to exactly
> match the actual implementation in mod_remoteip.c.
> First of all, both directives are combined into one single list (not two).
> In remoteip_modify_request() this is referred to as config->proxymatch_ip.
> The elements within this list are distinguished by the "internal" field.
> RemoteIPInternalProxy elements are marked as internal, while
> RemoteIPTrustedProxy elements are not.
> The only difference in processing of the "internal" field is in the
> handling of local/private subnets.
> So as I read the code, it is not a difference in level of trust, but
> rather a matter of name space.
> This makes sense to me.
> For example, IP address only has meaning within a specific local
> network.
> So if an external proxy is referring to, it would probably not be
> intending a server in the local network that just happens to have
> has its IP address.
> Secondly, with each cycle of the while loop the apparent client IP is
> compared against the proxymatch_ip list.
> It may be internal or not.
> There is nothing I see in the code that prevents a cycle with internal
> proxy from following a cycle with external proxy.
> So if your explanation is the way the code is intended, there may exist
> some subtle  error cases.
> Experiments to investigate this could take us outside the scope of the
> original bug reports, so I decided to discuss it here instead.
>>  The setups so far have not included a RemoteIPProxiesHeader.
>>> But if it is included, the mod_remote documentation seems to indicate
>>> that the value should be different from the RemoteIPHeader.
>>> -
>>> remoteipproxiesheader
>>> RemoteIPHeader  X-Forwarded-For
>>> RemoteIPProxiesHeader  X-Forwarded-By
>> You are correct.
>>   From my analysis so far it appears that mod_remoteip is behaving as
>>> documented. But the documentation is a little difficult to understand.
>> Correct, and I'm not sure how it can be improved.  Feel free to quote,
>> rephrase or build upon my responses to the bug tickets.

View raw message