> 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: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_remotei 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. https://issues.apache.org/bugzilla/show_bug.cgi?id=54651 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" <mike.ru...@oracle.com> wrote: > >On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote: >> On Mon, 09 Dec 2013 11:10:46 -0800 >> Mike Rumph <mike.ru...@oracle.com> 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: >>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=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 10.1.2.3 only has meaning within a specific >local network. >So if an external proxy is referring to 10.1.2.3, it would probably not >be intending a server in the local network that just happens to have >10.1.2.3 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. >>> - >>> >>>http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxies >>>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. >> >> >
