Re: [squid-users] Wrong IP number inserted into Forwarded-For header

Henrik

At 15:47 02/05/2002 +0200, Henrik Nordstrom wrote:
>Richard Barrett wrote:
>
> > Looks like Apache is not RFC compliant in this respect. I'll let the folks
> > there know.
>
>If Apache is RFC compliant or not depends on how they deal with this
>"per-connection record" information when there is conflicting requests on the
>same connection.
>
>Apache cannot be blaimed for the X-Forwarded-For IP spoofing not working.
>That is a hack module trying to spoof Apache into a situation that normally
>cannot ever happen (the IP address of the connection changes while the same
>connection is open). IP address information is a per-connection property by
>nature of HTTP.

I read TCP/IP 101 a while back and I know its a hack but in my particular
circumstances a necessary one. I was faced with having to move a well
established publicly accessible Apache server that used
domain-of-origin-of-incoming-connection-to-me as part of its security
scheme from on the firewall to inside, with Squid doing transparent
proxying for it on a bastion host in the DMZ. Being really dumb I added the
remote-IP rewriting module to Apache and didn't have to change anything
else on the Apache server barring its IP number to a private one. If you've
got any better suggestions for solving that problem quickly, don't hesitate
to call.

>I don't know the Apache internals to even speculate on what "connection
>record" parameters you think may be in conflict between different requests on
>the same connection.

Until I had the problem that arose with persistent connections between our
Squid proxy and our Apache server I didn't know much about Apache internals
either; but we all have to learn when problems arise so I did some
research: the information I garnered is below.

As for me blaming Apache for my woes; it seems to me that, quite
deliberately, Apache has two fields associated with user authentication
which, while they appear to be request related, are held in the 'shared'
connection record. In ref [1] below the author says in respect of these
authentication field: "We assume that there's only one user per connection(!)".

As I said two posts back:

>In particular, some requests containing no user authentication and others
>that do seem to be made down a common connection by Squid. I do not
>believe Squid should do this. If I understand correctly, some of the
>information associated with authentication is lodged in the Apache
>connection record rather than the request record and I presume that
>connection sharing by Squid might thus lead to problems similar to those I
>have experienced. I've not tried to prove this. I'm just hypothesising.

I think my comment that Apache may not be RFC compliant and the way Squid
RFC-compliantly uses persistent connections when connecting to an Apache
server might cause problems is a not unreasonable. But, if you don't agree,
that's fine with me.

If I've ever get the time I'll modify my request generating test scripts to
use basic authentication and see if adverse results occur. But, for now,
I've found and fixed the problem I had by turning
server_persistent_connections are off.

I genuinely appreciate the effort you and others have put into making Squid
available to people like me. Keep up the good work.

Richard

[1] Page 524 (Chapter 10: C API Reference Guide, Part 1 under the heading
The conn_rec structure) of Writing Apache Modules with Perl and C, Authors
Lincoln Stein and Doug MacEachern , Published by O'Reilly (First Edition
March 1999, ISBN: 1-56592-567-X, 746 pages) says:

<quote>
The conn_rec structure
----------------------

The connection record structure, conn_rec, contains information that is
specific to each client /server connection but not necessarily to each
request ... Within handlers, the current conn_rec is available inside the
request record's connection field. The same server child process will
process all request that are piggybacked on the same connection.

Most fields in the connection record are used internally by the server. Its
most common use in modules is to retrieve the user's login name during
authentication and to recover the client's IP address ...

...

char* user
If an authentication method is in use for the current connection, the user
field holds the login name provided by the user. The password cannot be ...

...

char* ap_auth_type
If authentication is in use for the current connection, this field will
hold the name of the authentication method ...

...
</quote>

Over the page, in Example 10-3 'The conn_rec Definition', the annotation
against the user and ap_auth_type fields reads:

<quote>
...

char* user; /* If an authentication check was made
                          * this gets set to the user name. We assume
                          * that there's only one user per connection(!)
                          */
char* ap_auth_type; /* Ditto. */

...
</quote>

[2] http://httpd.apache.org/dev/API-dict.html#conn_rec says:

<quote>
conn_rec
Definition:

typedef struct conn_rec conn_rec;
struct conn_rec {
     pool *pool;
     server_rec *server;
     server_rec *base_server;
     void *vhost_lookup_data;
     int child_num;
     BUFF *client;
     struct sockaddr_in local_addr;
     struct sockaddr_in remote_addr;
     char *remote_ip;
     char *remote_host;
     char *remote_logname;
     char *user;
     char *ap_auth_type;
     unsigned aborted:1;
     signed int keepalive:2;
     unsigned keptalive:1;
     signed int double_reverse:2;
     int keepalives;
};

Usage example:

No examples available.

No documentation available.
</quote

[3] http://httpd.apache.org/docs/misc/API.html says:

<quote>
Common routines, to handle the protocol end of things, at least for HTTP
basic authentication (ap_get_basic_auth_pw, which sets the connection->user
structure field automatically ...).
</quote>
Received on Thu May 02 2002 - 09:13:05 MDT