httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Rumph <>
Subject Re: mod_remoteip
Date Mon, 16 Dec 2013 19:06:32 GMT
Hello Eugene,

Thanks for pointing out your bug report 54651.
It answers a mystery I had with regard to bug report 55635.
As you can see in comment 1, I submitted results that were somewhat 
different from those of the bug reporter.
In comment 3, I gave an explanation of the bug reporter's results.
But that did not explain my own results.

Once I applied your patch from bug 54651, my results matched those of 
the bug reporter in 55635.
It appears that the bug reporter in 55635 had the patch for 54651 applied.
So I confirm that your patch is indeed valid and useful.

Since I am a relatively new developer (1 year) for the Apache httpd 
project, I do not have committer access.
Perhaps there is a committer who is interested in mod_remoteip that will 
consider committing the 54651 patch to trunk.
I will update bug 54651 to help bring it some attention.

Thanks again,

Mike Rumph

On 12/15/2013 1:00 AM, Lam, Eugene wrote:
>> Secondly, with each cycle of the while loop the apparent client IP is
> compared against the proxymatch_ip list.
> Are you referring to the while loop here:
> p.c?view=markup&pathrev=1550828#l247
> Not to detract from the original topic, but while we're here, an equally
> serious bug does exists on line 256 ... with a simple fix.
> If anyone would kindly verify and integrate the provided patch, this 1
> year old bug can be put to bed.
> EugeneL
> On 12/13/13 4: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.
>>>> -
>>>> header
>>>> 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