Mailing List Archive: Apache: Users

Re:

1 2

View All

Index | Next | Previous | View Threaded

covener at gmail

Nov 10, 2009, 5:28 AM

Post #1 of 31 (1682 views)
Permalink

Re:

On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <stephenlove [at] juno> wrote:
> I have set up a routine in my server that logs all incoming IP addresses and
> parses for duplicates in the same list. HOWEVER...a person posting almost
> NEVER has the same address. I believe I am not using the actual IP Address
> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!)
> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY
> TO address... the address it is COMMUNICATING FROM in order to actually send
> the message. I am SURE if it is to establish a 2-way link to send and
> confirm the message, the receiving end HAS that info, buried deep within
> what it receives. HOW can I get that, so that the route steps inbetween do
> not matter?

You don't have access to their MAC address or any other universal
identifier, no matter how much you use the shift key.

--
Eric Covener
covener [at] gmail

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

mearns.b at gmail

Nov 10, 2009, 7:52 AM

Post #2 of 31 (1648 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 8:28 AM, Eric Covener <covener [at] gmail> wrote:
> On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <stephenlove [at] juno> wrote:
>> I have set up a routine in my server that logs all incoming IP addresses and
>> parses for duplicates in the same list. HOWEVER...a person posting almost
>> NEVER has the same address. I believe I am not using the actual IP Address
>> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!)
>> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY
>> TO address... the address it is COMMUNICATING FROM in order to actually send
>> the message. I am SURE if it is to establish a 2-way link to send and
>> confirm the message, the receiving end HAS that info, buried deep within
>> what it receives. HOW can I get that, so that the route steps inbetween do
>> not matter?
>
> You don't have access to their MAC address or any other universal
> identifier, no matter how much you use the shift key.
>
> --
> Eric Covener
> covener [at] gmail
>
[clip]

As Eric says, what you're looking for is a MAC address which is a
universally unique identifier that every network device has (though I
think even here, "universally unique" might have some qualifying
conditions). MAC addresses are used in very low level protocols (link
layer protocols, I believe) to send packets to specific devices. MAC
addresses are for point-to-point communications, not end-to-end. You
could set up a packet sniffer, like Wireshark, and capture the source
MAC addresses of incoming packets, but that would probably just give
you the MAC address of your router or modem.

As you've discovered, IP addresses are not valid ways to identify end
users. Most residential internet access is done through a dynamic IP
address, meaning their ISP can change their IP address whenever it
wants. Further, a lot of people access the web through proxy servers,
so that a large number of end users are seen as the same IP address,
and others access through proxy pools or networks like Tor so that the
same person may have a different IP address for every request they
make.

It sounds like what you're looking for is a way to track your
visitors. Google Analytics is a pretty good free service for doing
exactly that, or you can set up your own similar system. The way these
things work is by using cookies to track individual browsers. But of
course, a lot of people don't use cookies. Further, if you're worried
about active menace, cookies are terribly insecure unless you're using
secure connections (and even then through various types of attack), so
a malicious user could snoop other people's cookies and submit it with
their own request, making it look like the request came from the other
user.

If you want to do more strict tracking, something along the lines of
"sorry, you already voted, and you can only vote once.", you'll need
to get much more sophisticated. Some sort of user-authentication
(i.e., "log in") is a must for this, and you'll need to be very
careful about people snooping cookies and log-in date (like, only use
secure HTTPS connections).

-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

rbowen at rcbowen

Nov 10, 2009, 8:55 AM

Post #3 of 31 (1643 views)
Permalink

Re: [In reply to]

On Nov 10, 2009, at 08:19 , Stephen Love wrote:

> I have set up a routine in my server that logs all incoming IP
> addresses and parses for duplicates in the same list. HOWEVER...a
> person posting almost NEVER has the same address. I believe I am not
> using the actual IP Address at all. What I WANT is the actual SERIAL
> NUMBER (If you could call it that!) of the HARDWARE (Network
> Adapter) actually sending the message, or its REPLY TO address...
> the address it is COMMUNICATING FROM in order to actually send the
> message. I am SURE if it is to establish a 2-way link to send and
> confirm the message, the receiving end HAS that info, buried deep
> within what it receives. HOW can I get that, so that the route steps
> inbetween do not matter?
>

No, you can't. It's impossible. That information (the MAC address)
doesn't make it past the first hop, and there's numerous pieces of
hardware (routers, firewalls, proxy servers, etc) between client and
server. The receiving end does NOT have that info, buried or
otherwise. It's simply not there.

--
Rich Bowen
rbowen [at] rcbowen

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

mwood at IUPUI

Nov 10, 2009, 11:31 AM

Post #4 of 31 (1642 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 10:52:18AM -0500, Brian Mearns wrote:
> As Eric says, what you're looking for is a MAC address which is a
> universally unique identifier that every network device has (though I
> think even here, "universally unique" might have some qualifying
> conditions).

Yes. Occasionally a manufacturer goofs and issues more than one part
with the same MAC address burned in. We received two desktop boxes
with the same MAC address once. Imagine how often it happens and
isn't caught, because they went to two different customers. :-(

Also, the IEEE 802 standards define Locally Administered Addresses.
Essentially you can tell most Ethernet adaptors to use any MAC address
you please, so long as a particular bit is on.*

A further complication is that at any time, someone could have a NIC
fail, replace it, and wind up using a different MAC address from then
on. Is that one user, or two? You don't know.

> MAC addresses are used in very low level protocols (link
> layer protocols, I believe) to send packets to specific devices. MAC
> addresses are for point-to-point communications, not end-to-end.

To make this plainer: the first router on the path from user X to you
will discard this information. As far as the protocol stack is
concerned, it has no useful meaning beyond that point.

It's thus very unlikely that you will get any help from hardware
manufacturers in identifying remote users or hosts in the manner you
specified. You'll need cooperation from your users.

-----------------
* DECnet Phase IV used this to encode the network-layer address in
the link-layer address, so the same NIC would have two different
MAC addresses depending on whether DECnet had been started. And
the LAA would change if you ever changed the network-layer
address. What fun.

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Friends don't let friends publish revisable-form documents.

aw at ice-sa

Nov 10, 2009, 12:49 PM

Post #5 of 31 (1641 views)
Permalink

Re: [In reply to]

Mark H. Wood wrote:
...
>
> It's thus very unlikely that you will get any help from hardware
> manufacturers in identifying remote users or hosts in the manner you
> specified. You'll need cooperation from your users.
>
And I would add that, from a user point of view, I would be very
reluctant to help at any system that would let me be identified in any
way other than me voluntarily and knowingly providing my id by means of
some obvious login page or certificate, and then only to some party I
trust not to disseminate that information outside of my control.
And enough recent cases have shown that such trustable parties are not
very thick on the ground.
So independently of the technical issues, you are up against some
guaranteed and well-founded resistance.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

kremels at kreme

Nov 10, 2009, 2:06 PM

Post #6 of 31 (1643 views)
Permalink

Re: [In reply to]

On 10-Nov-2009, at 13:49, André Warnier wrote:
> And I would add that, from a user point of view, I would be very reluctant to help at any system that would let me be identified in any way other than me voluntarily and knowingly providing my id by means of some obvious login page or certificate, and then only to some party I trust not to disseminate that information outside of my control.
> And enough recent cases have shown that such trustable parties are not very thick on the ground.

Heck, I don't even trust MYSELF that much.

--
'They say that whoever pays the piper calls the tune.'
'But, gentlemen,' said Mr Saveloy, 'whoever holds a knife to the piper's throat writes the symphony.' --Interesting Times

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

stephenlove at juno

Nov 10, 2009, 3:19 PM

Post #7 of 31 (1641 views)
Permalink

Re: [In reply to]

You're getting close. I don't want ANY personal data. Just to know that it is really them and that the next time I see them I will see the same number. I simply want a REAL visitor and hit count. NO PERSONAL DATA of ANY KIND... just GUARANTEED UNIQUE to the user.

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Brian Mearns <mearns.b [at] gmail>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Tue, 10 Nov 2009 10:52:18 -0500

On Tue, Nov 10, 2009 at 8:28 AM, Eric Covener <covener [at] gmail> wrote:
> On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <stephenlove [at] juno> wrote:
>> I have set up a routine in my server that logs all incoming IP addresses and
>> parses for duplicates in the same list. HOWEVER...a person posting almost
>> NEVER has the same address. I believe I am not using the actual IP Address
>> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!)
>> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY
>> TO address... the address it is COMMUNICATING FROM in order to actually send
>> the message. I am SURE if it is to establish a 2-way link to send and
>> confirm the message, the receiving end HAS that info, buried deep within
>> what it receives. HOW can I get that, so that the route steps inbetween do
>> not matter?
>
> You don't have access to their MAC address or any other universal
> identifier, no matter how much you use the shift key.
>
> --
> Eric Covener
> covener [at] gmail
>
[clip]

As Eric says, what you're looking for is a MAC address which is a
universally unique identifier that every network device has (though I
think even here, "universally unique" might have some qualifying
conditions). MAC addresses are used in very low level protocols (link
layer protocols, I believe) to send packets to specific devices. MAC
addresses are for point-to-point communications, not end-to-end. You
could set up a packet sniffer, like Wireshark, and capture the source
MAC addresses of incoming packets, but that would probably just give
you the MAC address of your router or modem.

As you've discovered, IP addresses are not valid ways to identify end
users. Most residential internet access is done through a dynamic IP
address, meaning their ISP can change their IP address whenever it
wants. Further, a lot of people access the web through proxy servers,
so that a large number of end users are seen as the same IP address,
and others access through proxy pools or networks like Tor so that the
same person may have a different IP address for every request they
make.

It sounds like what you're looking for is a way to track your
visitors. Google Analytics is a pretty good free service for doing
exactly that, or you can set up your own similar system. The way these
things work is by using cookies to track individual browsers. But of
course, a lot of people don't use cookies. Further, if you're worried
about active menace, cookies are terribly insecure unless you're using
secure connections (and even then through various types of attack), so
a malicious user could snoop other people's cookies and submit it with
their own request, making it look like the request came from the other
user.

If you want to do more strict tracking, something along the lines of
"sorry, you already voted, and you can only vote once.", you'll need
to get much more sophisticated. Some sort of user-authentication
(i.e., "log in") is a must for this, and you'll need to be very
careful about people snooping cookies and log-in date (like, only use
secure HTTPS connections).

-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
____________________________________________________________
Free Copier Price Quotes
Get free copier price quotes from multiple dealers and save!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=jZ2grMgTNGhOrcjPvWqZugAAJz1cSR5zxtI8-KAHzBSY23cQAAQAAAAFAAAAAPLSTT4AAAMlAAAAAAAAAAAAAAAAABIVZAAAAAA=

stephenlove at juno

Nov 10, 2009, 3:20 PM

Post #8 of 31 (1642 views)
Permalink

Re: [In reply to]

So what you are telling me is that there IS no REAL 2-way handshaking going on. Then we've lost ALL hope of security.

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Rich Bowen <rbowen [at] rcbowen>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Tue, 10 Nov 2009 11:55:05 -0500

On Nov 10, 2009, at 08:19 , Stephen Love wrote:

> I have set up a routine in my server that logs all incoming IP
> addresses and parses for duplicates in the same list. HOWEVER...a
> person posting almost NEVER has the same address. I believe I am not
> using the actual IP Address at all. What I WANT is the actual SERIAL
> NUMBER (If you could call it that!) of the HARDWARE (Network
> Adapter) actually sending the message, or its REPLY TO address...
> the address it is COMMUNICATING FROM in order to actually send the
> message. I am SURE if it is to establish a 2-way link to send and
> confirm the message, the receiving end HAS that info, buried deep
> within what it receives. HOW can I get that, so that the route steps
> inbetween do not matter?
>

No, you can't. It's impossible. That information (the MAC address)
doesn't make it past the first hop, and there's numerous pieces of
hardware (routers, firewalls, proxy servers, etc) between client and
server. The receiving end does NOT have that info, buried or
otherwise. It's simply not there.

--
Rich Bowen
rbowen [at] rcbowen

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
____________________________________________________________
Free Copier Price Quotes
Get free copier price quotes from multiple dealers and save!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=0LuXbYcQxGi7Lq9uayJHvwAAJz1cSR5zxtI8-KAHzBSY23cQAAQAAAAFAAAAAPLSTT4AAAMlAAAAAAAAAAAAAAAAABIVZAAAAAA=

stephenlove at juno

Nov 10, 2009, 3:24 PM

Post #9 of 31 (1643 views)
Permalink

Re: [In reply to]

Don't want identification. I want point to point response capability, even if it goes away later... a way to know that I can send back to that exact address and know it went to that particular computer instead of randomly going all over the world. Sounds like either I have been misinformed about how packets are sent, or a LOT of programmers simply do not know the truth! 2-way handshaking requires session identification ALL the way back to its source.

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: LuKreme <kremels [at] kreme>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Tue, 10 Nov 2009 15:06:51 -0700

On 10-Nov-2009, at 13:49, André Warnier wrote:
> And I would add that, from a user point of view, I would be very reluctant to help at any system that would let me be identified in any way other than me voluntarily and knowingly providing my id by means of some obvious login page or certificate, and then only to some party I trust not to disseminate that information outside of my control.
> And enough recent cases have shown that such trustable parties are not very thick on the ground.

Heck, I don't even trust MYSELF that much.

--
'They say that whoever pays the piper calls the tune.'
'But, gentlemen,' said Mr Saveloy, 'whoever holds a knife to the piper's throat writes the symphony.' --Interesting Times

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
____________________________________________________________
Business Security Camera Quotes
Get free business security camera price quotes from multiple dealers!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=oAsl4Bai_493n9q9V-CLawAAJz1cSR5zxtI8-KAHzBSY23cQAAQAAAAFAAAAAOOlGz0AAANSAAAAAAAAAAAAAAAAABIVYgAAAAA=

covener at gmail

Nov 10, 2009, 3:37 PM

Post #10 of 31 (1637 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 6:20 PM, Stephen Love <stephenlove [at] juno> wrote:
> So what you are telling me is that there IS no REAL 2-way handshaking going
> on. Then we've lost ALL hope of security.
>

What's "REAL" in this context? It's not authenticated and doesn't
result in some session establishment unless you configure your
application to require/manage such a thing?

--
Eric Covener
covener [at] gmail

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

covener at gmail

Nov 10, 2009, 4:06 PM

Post #11 of 31 (1640 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 6:24 PM, Stephen Love <stephenlove [at] juno> wrote:
> Don't want identification. I want point to point response capability, even
> if it goes away later... a way to know that I can send back to that exact
> address and know it went to that particular computer instead of randomly
> going all over the world. Sounds like either I have been misinformed about
> how packets are sent, or a LOT of programmers simply do not know the truth!
> 2-way handshaking requires session identification ALL the way back to its
> source.

You get all this from TCP, you just can't make any statement about
how different TCP connections over time are related (as your OP
implied)

--
Eric Covener
covener [at] gmail

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

spc at conman

Nov 10, 2009, 4:35 PM

Post #12 of 31 (1634 views)
Permalink

Re: [In reply to]

It was thus said that the Great Stephen Love once stated:
> So what you are telling me is that there IS no REAL 2-way handshaking
> going on. Then we've lost ALL hope of security.

There is a 2-way handshake, but it's at the TCP layer, which is used to
establish a reliable, stream-oriented sequence of data. As far as the
browser and server are concerned, they're talking directly to each other:

HTTP client <-----> HTTP server

but in reality, the HTTP protocol is wrapped in the TCP layer:

HTTP client HTTP server
^ ^
| |
v v
TCP <-------------------> TCP

but in reality, the TCP protocol (which establishes reliability and a
stream oriented (or line oriented if you care to view it that way) over the
IP protocol (which itself doesn't guarentee reliability, and is packet
oriented, not stream-oriented):

HTTP client HTTP server
^ ^
| |
v v
TCP TCP
^ ^
| |
v v
IP <-----------------------> IP

And thus completes a full TCP/IP connection. IP itself is embedded in a
multitude of hardware layer protocols, like Ethernet, T1 (which has a few
framing protocols itself), PPP, PPPoE, SCSI [1] or even avian carriers
[2][3], so the lower layers of the stack (below the IP layer) that get
stripped and added as the packet makes it way across the Internet. An
example might look like:

HTTP client HTTP server
^ ^
| |
v v
TCP TCP
^ ^
| |
v v
IP +- IP --+ +- IP --+ IP
^ | | | | ^
| | | | | |
v v v v v v
Ethernet <--> Ethernet T1 <--> T1 Ethernet <--> Ethernet
client router router server
^
|
Any number of hops here

(also note that the T1 listed here is just an example; it most likely is
PPPoE over ATM (which comprises DSL I think), so there may even be a few
layers below the IP layer)

The MAC address of the client doesn't even survive the first hop. The
server ends up with the MAC address of the router as the "sender", even
though the IP packet comes from the client somewhere else on the Internet.

It helps to think of it this way: IP allows individual computers to
communiate; TCP allows individual programs to communiate.

Once you get a connection, you have a few pieces of information about the
other side:

it's an HTTP connection (a given)
over a TCP connection (a given)
the local side's TCP port # (usually 80 if HTTP)
the local side's IP address (typically a given)
the remote side's TCP port #
the remote site's IP address

If you want more unique inforamtion, then you need to look into stuff like
cookies and session management (which is beyond the scope of HTTP for the
most part).

-spc (Hope this clears up some misconceptions)

[1] RFC-2143 [5]

[2] RFC-1149, updated by RFC-2549

[3] No, really! It's even been done. [4]

[4] http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

[5] RFCs are documents that document the various Internet standards.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

stephenlove at juno

Nov 10, 2009, 7:29 PM

Post #13 of 31 (1629 views)
Permalink

Re: [In reply to]

Ok, now we're getting somewhere... just ENOUGH to eliminate the path inbetween... I'd just like to ask APACHE for a unique signature of the machine sending the message to compare it against others. Nothing more, nothing less.

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Sean Conner <spc [at] conman>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Tue, 10 Nov 2009 19:35:39 -0500

It was thus said that the Great Stephen Love once stated:
> So what you are telling me is that there IS no REAL 2-way handshaking
> going on. Then we've lost ALL hope of security.

There is a 2-way handshake, but it's at the TCP layer, which is used to
establish a reliable, stream-oriented sequence of data. As far as the
browser and server are concerned, they're talking directly to each other:

HTTP client <-----> HTTP server

but in reality, the HTTP protocol is wrapped in the TCP layer:

HTTP client HTTP server
^ ^
| |
v v
TCP <-------------------> TCP

but in reality, the TCP protocol (which establishes reliability and a
stream oriented (or line oriented if you care to view it that way) over the
IP protocol (which itself doesn't guarentee reliability, and is packet
oriented, not stream-oriented):

HTTP client HTTP server
^ ^
| |
v v
TCP TCP
^ ^
| |
v v
IP <-----------------------> IP

And thus completes a full TCP/IP connection. IP itself is embedded in a
multitude of hardware layer protocols, like Ethernet, T1 (which has a few
framing protocols itself), PPP, PPPoE, SCSI [1] or even avian carriers
[2][3], so the lower layers of the stack (below the IP layer) that get
stripped and added as the packet makes it way across the Internet. An
example might look like:

HTTP client HTTP server
^ ^
| |
v v
TCP TCP
^ ^
| |
v v
IP +- IP --+ +- IP --+ IP
^ | | | | ^
| | | | | |
v v v v v v
Ethernet <--> Ethernet T1 <--> T1 Ethernet <--> Ethernet
client router router server
^
|
Any number of hops here

(also note that the T1 listed here is just an example; it most likely is
PPPoE over ATM (which comprises DSL I think), so there may even be a few
layers below the IP layer)

The MAC address of the client doesn't even survive the first hop. The
server ends up with the MAC address of the router as the "sender", even
though the IP packet comes from the client somewhere else on the Internet.

It helps to think of it this way: IP allows individual computers to
communiate; TCP allows individual programs to communiate.

Once you get a connection, you have a few pieces of information about the
other side:

it's an HTTP connection (a given)
over a TCP connection (a given)
the local side's TCP port # (usually 80 if HTTP)
the local side's IP address (typically a given)
the remote side's TCP port #
the remote site's IP address

If you want more unique inforamtion, then you need to look into stuff like
cookies and session management (which is beyond the scope of HTTP for the
most part).

-spc (Hope this clears up some misconceptions)

[1] RFC-2143 [5]

[2] RFC-1149, updated by RFC-2549

[3] No, really! It's even been done. [4]

[4] http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

[5] RFCs are documents that document the various Internet standards.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

____________________________________________________________
Diet Help
Cheap Diet Help Tips. Click here.
http://thirdpartyoffers.juno.com/TGL2131/c?cp=ReODJzUqRaF2DtAK679qBAAAJz1cSR5zxtI8-KAHzBSY23cQAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAYQAAAAAA=

mearns.b at gmail

Nov 10, 2009, 7:34 PM

Post #14 of 31 (1628 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 6:37 PM, Eric Covener <covener [at] gmail> wrote:
> On Tue, Nov 10, 2009 at 6:20 PM, Stephen Love <stephenlove [at] juno> wrote:
>> So what you are telling me is that there IS no REAL 2-way handshaking going
>> on. Then we've lost ALL hope of security.
>>
>
> What's "REAL" in this context? It's not authenticated and doesn't
> result in some session establishment unless you configure your
> application to require/manage such a thing?
>
> --
> Eric Covener
> covener [at] gmail
[clip]

Yes, why don't you tell us exactly what you want to do, what's your
end goal? Visitor stats? Geographic locating? Authentication of a
real-world identity? There's a lot of very bright and very
knowledgeable people on this list, so if there's any way at all to do
what you want, then there is a very good chance that somebody here
will be able to tell you. It just might not be done the way you think
it should be.

As many of us have said, TCP is an end to end protocol. And in fact,
it is stateful, so you can send messages back and forth between the
two end points for as long as the connection is open. There is a
handshake that goes on between the two end points to setup this
connection, but this is not any sort of real authentication process
that confirms the identity of either end. What TCP gets you is pretty
good confidence that you are talking to the same person you were when
you started the conversation, but even that confidence is really only
upheld in the absence of active attacks like IP spoofing, and it
provides absolutely no confidence that there aren't other people
listening to the conversation, and potentially even participating in
the conversation.

If you're looking for security: like making sure no one else is
listening to the conversation, no one else is modifying the
conversation data, and or making sure that the person on the other end
is who they claim to be...then you're going to need a much more
sophisticated protocol than TCP, IP, or HTTP. SSL/TLS provides all
these things, with the latest TLS version believed to be quite secure
with current technologies and techniques. HTTPS layers HTTP over a
secure SSL or TLS connection, and is available in Apache with mod_ssl.

Your comment that "we've lost ALL hope of security" is quite accurate
with regards to HTTP, TCP, and IP alone. These protocols were really
not designed with any attention to security as security wasn't really
an acknowledged concern at the time they were created. Thus we have
add on protocols like SSL and TLS.

Anyway, back to my point: tell us what you're actually trying to do
and there's a good chance someone can help you, as long as you're
willing to let go of any preconceived notions on how to get the job
done (that's always the biggest stumbling block to learning something
new).

Cheers,
-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

mearns.b at gmail

Nov 10, 2009, 7:42 PM

Post #15 of 31 (1631 views)
Permalink

Re: [In reply to]

On Tue, Nov 10, 2009 at 10:29 PM, Stephen Love <stephenlove [at] juno> wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of the
> machine sending the message to compare it against others. Nothing more,
> nothing less.
>
>
> See us online at http://www.LOVEnCompany.com.
>

Well, see my most recent message, but just to summarize, apache can't
uniquely identify the end machine on it's own, all it has is what that
machine send to it, which is IP packet, which contains the TCP packet,
which contains the HTTP packet, none of which include (on their own) a
unique identifier for the end machine. The best you can do with just
these protocols is generate a unique id, send it to the client, and
ask them to send it back. You can do this using cookies, or by
encoding the id in the URL. But either way, you're relying on the end
user to cooperate (i.e., send back the same identifier). If you're
looking for something that they can't reasonably fake or alter without
your knowing, you'll need a crypto protocol like TLS (again, see my
last message).

-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

npeelman at cfl

Nov 10, 2009, 10:00 PM

Post #16 of 31 (1622 views)
Permalink

Re: [In reply to]

Stephen Love wrote:
>
> Don't want identification. I want point to point response capability,
> even if it goes away later... a way to know that I can send back to
> that exact address and know it went to that particular computer
> instead of randomly going all over the world. Sounds like either I
> have been misinformed about how packets are sent, or a LOT of
> programmers simply do not know the truth! 2-way handshaking requires
> session identification ALL the way back to its source.
>
>
Sorry, but it doesn't work that way. The IP address is the only thing
you can go by and that can change on a request basis. The IP address is
the 'street address' you want but they are not all assigned permanently
at this time.

--
Norman Registered Linux user #461062

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

npeelman at cfl

Nov 10, 2009, 10:07 PM

Post #17 of 31 (1627 views)
Permalink

Re: [In reply to]

Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of the
> machine sending the message to compare it against others. Nothing
> more, nothing less.
>
>

nope...

--
Norman Registered Linux user #461062

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

aw at ice-sa

Nov 11, 2009, 12:52 AM

Post #18 of 31 (1614 views)
Permalink

Re: [In reply to]

Stephen Love wrote:
> Ok, now we're getting somewhere... just ENOUGH to eliminate the path inbetween... I'd just like to ask APACHE for a unique signature of the machine sending the message to compare it against others. Nothing more, nothing less.
>
>
> See us online at http://www.LOVEnCompany.com.
>
Well, it looks like this list already gave you all the possible
human-level help. If that does not solve your problem, maybe you should
ask for some higher-level intervention.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

SamanKaya at netscape

Nov 11, 2009, 4:54 AM

Post #19 of 31 (1600 views)
Permalink

Re: [In reply to]

André Warnier wrote:
> Stephen Love wrote:
>> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
>> inbetween... I'd just like to ask APACHE for a unique signature of
>> the machine sending the message to compare it against others. Nothing
>> more, nothing less.
>>
>>
>> See us online at http://www.LOVEnCompany.com.
>>
> Well, it looks like this list already gave you all the possible
> human-level help. If that does not solve your problem, maybe you
> should ask for some higher-level intervention.
>
>
>
Please check the OSI systems stack for further information which is
directly compatible with the TCP/IP system's stack - in fact it's kind
of an expanded version that all network engineers use!!

Basically in the underlying network components you have physical, media
access, and network layers (1-3); layers 4-7 usually deal with the
computers themselves which start from ports and go to the apps themselves.

Now layer 2, at least true for Ethernet means that the MAC address of
the system is only point to point between machine and switch port, after
that things change. Layer 3 is convoluted by the intervention of NAT or
proxy so the only thing you are likely to get is the WAN IP address of
the network.

Unique identifiers are impossible, even using Cisco's proprietary CDP
(cisco discovery protocol) which discoverers neighboring Cisco devices
cannot go beyond next hop device as uses layer 2 addressing as reference!!!

The only way I suppose in theory one could do what you are after is for
the user to download a little app that has a unique signature and
broadcasts the full system info according to that. So at least with the
client part of the program you could have say 1 x 10^50 unique
signatures generated by a shell script or program then link them to a
server somewhere...... I do believe this is called spyware though and is
highly illegal!!!

In all honesty I think the best way is going through webalizer, GeoIP,
awstats, or Ntop!!! And if going through reverse proxy with Squid like
me; unlike me you can form the logs of Squid in a different way and
hence forward those to Apache, then get Apache to read those 'different'
logs so that you have the correct data collection available to you........
As far as I know of this would be about the only way to go! At least you
get the WAN IP of the remote network and can collect and collate
geographic locational information and also ISP info too :-)

Without using divine power or alien intervention.......

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

john.iliffe at iliffe

Nov 11, 2009, 9:24 AM

Post #20 of 31 (1592 views)
Permalink

Re: Spam:*, Re: [users@httpd] [In reply to]

On Wed, 2009-11-11 at 14:54 +0200, Kaya Saman wrote:
> AndrÃ© Warnier wrote:
> > Stephen Love wrote:
> >> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> >> inbetween... I'd just like to ask APACHE for a unique signature of
> >> the machine sending the message to compare it against others. Nothing
> >> more, nothing less.
> >>
> >>
> >> See us online at http://www.LOVEnCompany.com.
> >>
> > Well, it looks like this list already gave you all the possible
> > human-level help. If that does not solve your problem, maybe you
> > should ask for some higher-level intervention.
> >
> >
> >
> Please check the OSI systems stack for further information which is
> directly compatible with the TCP/IP system's stack - in fact it's kind
> of an expanded version that all network engineers use!!
>
> Basically in the underlying network components you have physical, media
> access, and network layers (1-3); layers 4-7 usually deal with the
> computers themselves which start from ports and go to the apps themselves.
>
> Now layer 2, at least true for Ethernet means that the MAC address of
> the system is only point to point between machine and switch port, after
> that things change. Layer 3 is convoluted by the intervention of NAT or
> proxy so the only thing you are likely to get is the WAN IP address of
> the network.
>
> Unique identifiers are impossible, even using Cisco's proprietary CDP
> (cisco discovery protocol) which discoverers neighboring Cisco devices
> cannot go beyond next hop device as uses layer 2 addressing as reference!!!
>
> The only way I suppose in theory one could do what you are after is for
> the user to download a little app that has a unique signature and
> broadcasts the full system info according to that. So at least with the
> client part of the program you could have say 1 x 10^50 unique
> signatures generated by a shell script or program then link them to a
> server somewhere...... I do believe this is called spyware though and is
> highly illegal!!!
>
> In all honesty I think the best way is going through webalizer, GeoIP,
> awstats, or Ntop!!! And if going through reverse proxy with Squid like
> me; unlike me you can form the logs of Squid in a different way and
> hence forward those to Apache, then get Apache to read those 'different'
> logs so that you have the correct data collection available to you........
> As far as I know of this would be about the only way to go! At least you
> get the WAN IP of the remote network and can collect and collate
> geographic locational information and also ISP info too :-)
>
> Without using divine power or alien intervention.......
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe [at] httpd
> " from the digest: users-digest-unsubscribe [at] httpd
> For additional commands, e-mail: users-help [at] httpd
>
Isn't this being discussed in the wrong forum?

What is ***looks*** like is that you have a class of computers that you
need to query to find out which one sent the message/packet/transaction
or whatever. This is the classic case for a digital signature.

The group has to be reasonably finite since you need to have a public
key for each computer that you need to authenticate. Then send
something in each packet that has to be encrypted under the senders
private key. You can authenticate that it came from that sender by
decrypting under its public key. If the result is the original token,
then you can be reasonably certain where the message originated.

John

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

rbowen at rcbowen

Nov 11, 2009, 9:55 AM

Post #21 of 31 (1598 views)
Permalink

Re: [In reply to]

On Nov 10, 2009, at 22:29 , Stephen Love wrote:

> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
> inbetween... I'd just like to ask APACHE for a unique signature of
> the machine sending the message to compare it against others.
> Nothing more, nothing less.

Take a look at mod_usertrack: http://httpd.apache.org/docs/2.2/mod/mod_usertrack.html
If you don't trust cookies, then you're out of luck.

--
Rich Bowen
rbowen [at] rcbowen

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

aw at ice-sa

Nov 11, 2009, 10:48 AM

Post #22 of 31 (1587 views)
Permalink

Re: [In reply to]

Rich Bowen wrote:
>
> On Nov 10, 2009, at 22:29 , Stephen Love wrote:
>
>> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
>> inbetween... I'd just like to ask APACHE for a unique signature of the
>> machine sending the message to compare it against others. Nothing
>> more, nothing less.
>
>
> Take a look at mod_usertrack:
> http://httpd.apache.org/docs/2.2/mod/mod_usertrack.html
> If you don't trust cookies, then you're out of luck.
>
(many) People on this forum have been trying to convince the OP in
(many) previous messages, some of them containing a wealth of
information and having required significant time to write, that the only
practical technical solution for what he seems to want to do, was using
cookies.
It is just that somehow he seems not to be of the believing kind.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

stephenlove at juno

Nov 11, 2009, 1:21 PM

Post #23 of 31 (1579 views)
Permalink

Re: [In reply to]

Then it becomes impossible to know if a page REALLY exists or if my emails are going where intended, or coming from where stated... so am I to assume that traffic addressing in general has FAILED?

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Kaya Saman <SamanKaya [at] netscape>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Wed, 11 Nov 2009 14:54:31 +0200

André Warnier wrote:
> Stephen Love wrote:
>> Ok, now we're getting somewhere... just ENOUGH to eliminate the path
>> inbetween... I'd just like to ask APACHE for a unique signature of
>> the machine sending the message to compare it against others. Nothing
>> more, nothing less.
>>
>>
>> See us online at http://www.LOVEnCompany.com.
>>
> Well, it looks like this list already gave you all the possible
> human-level help. If that does not solve your problem, maybe you
> should ask for some higher-level intervention.
>
>
>
Please check the OSI systems stack for further information which is
directly compatible with the TCP/IP system's stack - in fact it's kind
of an expanded version that all network engineers use!!

Basically in the underlying network components you have physical, media
access, and network layers (1-3); layers 4-7 usually deal with the
computers themselves which start from ports and go to the apps themselves.

Now layer 2, at least true for Ethernet means that the MAC address of
the system is only point to point between machine and switch port, after
that things change. Layer 3 is convoluted by the intervention of NAT or
proxy so the only thing you are likely to get is the WAN IP address of
the network.

Unique identifiers are impossible, even using Cisco's proprietary CDP
(cisco discovery protocol) which discoverers neighboring Cisco devices
cannot go beyond next hop device as uses layer 2 addressing as reference!!!

The only way I suppose in theory one could do what you are after is for
the user to download a little app that has a unique signature and
broadcasts the full system info according to that. So at least with the
client part of the program you could have say 1 x 10^50 unique
signatures generated by a shell script or program then link them to a
server somewhere...... I do believe this is called spyware though and is
highly illegal!!!

In all honesty I think the best way is going through webalizer, GeoIP,
awstats, or Ntop!!! And if going through reverse proxy with Squid like
me; unlike me you can form the logs of Squid in a different way and
hence forward those to Apache, then get Apache to read those 'different'
logs so that you have the correct data collection available to you........
As far as I know of this would be about the only way to go! At least you
get the WAN IP of the remote network and can collect and collate
geographic locational information and also ISP info too :-)

Without using divine power or alien intervention.......

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
____________________________________________________________
Weight Loss Program
Best Weight Loss Program - Click Here!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=onFXOzZvc1_g2DgjfumvRgAAJz1cSR5zxtI8-KAHzBSY23cQAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAEUgAAAAA=

stephenlove at juno

Nov 11, 2009, 1:28 PM

Post #24 of 31 (1583 views)
Permalink

Re: [In reply to]

Hmmm... somewhat new to the inner details... all I know is what I research on my own... have not had a book-learning course on this... but TLS... what is that? AND... I simply want a list of source identifiers of incoming requests so that I can check each new one for duplicate incoming source... just a HITS vs UNIQUE VISITORS. I want NOTHING MORE. I can do add'l tracking based on time, date, etc, on my own. Just site usage statistics.

See us online at http://www.LOVEnCompany.com.

---------- Original Message ----------
From: Brian Mearns <mearns.b [at] gmail>
To: users [at] httpd
Subject: Re: [users [at] http]
Date: Tue, 10 Nov 2009 22:34:24 -0500

On Tue, Nov 10, 2009 at 6:37 PM, Eric Covener <covener [at] gmail> wrote:
> On Tue, Nov 10, 2009 at 6:20 PM, Stephen Love <stephenlove [at] juno> wrote:
>> So what you are telling me is that there IS no REAL 2-way handshaking going
>> on. Then we've lost ALL hope of security.
>>
>
> What's "REAL" in this context? It's not authenticated and doesn't
> result in some session establishment unless you configure your
> application to require/manage such a thing?
>
> --
> Eric Covener
> covener [at] gmail
[clip]

Yes, why don't you tell us exactly what you want to do, what's your
end goal? Visitor stats? Geographic locating? Authentication of a
real-world identity? There's a lot of very bright and very
knowledgeable people on this list, so if there's any way at all to do
what you want, then there is a very good chance that somebody here
will be able to tell you. It just might not be done the way you think
it should be.

As many of us have said, TCP is an end to end protocol. And in fact,
it is stateful, so you can send messages back and forth between the
two end points for as long as the connection is open. There is a
handshake that goes on between the two end points to setup this
connection, but this is not any sort of real authentication process
that confirms the identity of either end. What TCP gets you is pretty
good confidence that you are talking to the same person you were when
you started the conversation, but even that confidence is really only
upheld in the absence of active attacks like IP spoofing, and it
provides absolutely no confidence that there aren't other people
listening to the conversation, and potentially even participating in
the conversation.

If you're looking for security: like making sure no one else is
listening to the conversation, no one else is modifying the
conversation data, and or making sure that the person on the other end
is who they claim to be...then you're going to need a much more
sophisticated protocol than TCP, IP, or HTTP. SSL/TLS provides all
these things, with the latest TLS version believed to be quite secure
with current technologies and techniques. HTTPS layers HTTP over a
secure SSL or TLS connection, and is available in Apache with mod_ssl.

Your comment that "we've lost ALL hope of security" is quite accurate
with regards to HTTP, TCP, and IP alone. These protocols were really
not designed with any attention to security as security wasn't really
an acknowledged concern at the time they were created. Thus we have
add on protocols like SSL and TLS.

Anyway, back to my point: tell us what you're actually trying to do
and there's a good chance someone can help you, as long as you're
willing to let go of any preconceived notions on how to get the job
done (that's always the biggest stumbling block to learning something
new).

Cheers,
-Brian

--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
____________________________________________________________
Pharmacy Assistant School
Earn a Pharmacy Technician Degree. Get free info and Apply Today!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=WBLHA3h-sZmvJlqBAjcAQQAAJz1cSR5zxtI8-KAHzBSY23cQAAQAAAAFAAAAAKwcGj4AAANSAAAAAAAAAAAAAAAAABNldwAAAAA=

rbowen at rcbowen

Nov 11, 2009, 1:48 PM

Post #25 of 31 (1588 views)
Permalink

Re: [In reply to]

On Nov 11, 2009, at 16:28 , Stephen Love wrote:

> Hmmm... somewhat new to the inner details... all I know is what I
> research on my own... have not had a book-learning course on this...
> but TLS... what is that? AND... I simply want a list of source
> identifiers of incoming requests so that I can check each new one
> for duplicate incoming source... just a HITS vs UNIQUE VISITORS. I
> want NOTHING MORE. I can do add'l tracking based on time, date, etc,
> on my own. Just site usage statistics.

Your question has now been answered several times. I have recommended
mod_usertrack. You may use cookies that you have crafted yourself,
either in some server-side application, or perhaps with mod_rewrite.
If you do not trust cookies, then there is no way to do what you're
trying to do. You cannot uniquely identify the visitor in the way that
you are describing, other than with cookies, or using a third-party
service, like Google Analytics, which relies on cookies.

Yes, cookies are unreliable and hackable, but they're the best we have
to offer. Repeating your question with increasing belligerence will
not change this reality. This is the answer to your question. There
are no other answers, no matter how much you want for there to be.

On the other hand, how much does it *really* matter whether you have
1,000,000 or 1,000,001 visitors? Sometimes, you just have to be
satisfied with a really good estimate.

--
Rich Bowen
rbowen [at] rcbowen

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads