On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote:
On Mon, 09 Dec 2013 11:10:46 -0800
Mike Rumph <[email protected]> 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#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.
