httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Love" <>
Subject Re: [users@httpd]
Date Wed, 11 Nov 2009 03:29:45 GMT
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

---------- Original Message ----------
From: Sean Conner <>
Subject: Re: [users@httpd]
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
  ^    ^
  |    |
  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]


[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:> for more info.
To unsubscribe, e-mail:
  "   from the digest:
For additional commands, e-mail:

Diet Help
Cheap Diet Help Tips. Click here.
View raw message