[MUD-Dev] Re: Quick question re: SSL
ceo
ceo at grexengine.com
Mon Mar 8 22:44:47 CET 2004
FYI for two misunderstandings...
Alex Chacha wrote:
> Adam M wrote:
>> How, exactly, do you do this with HTTP?
> That depends on who's HTTP server implementation you use. If you
> are just doing sockets, then when you receive connection, you also
> receive the remote IP address (sockaddr_in). If you are using a
> web server (CGI, plugin, etc) then the server has a context
> structure it passes or you can query that contains the remote IP
> address. If you are using Mfc/Win32 then socket class has the
> methods to access it. Same thing in Java sockets. The HTTP
> protocol rides on top of TCP/IP and thus you can get the remote IP
> address.
This is all irrelevant, I'm afraid.
You do *not* get the remote IP address with the HTTP protocol, you
get the address of potentially any random webcache on the internet
who received your request. It is not uncommon for the same request
to be routed through a chain of multiple caches - and if you're
interested this scenario is covered in depth in RFC 2616.
Even TCP is irrelevant here, because the opened TCP connection comes
from the relayer (i.e. the cache) not from the client.
SSL is different because of the optional explicit authentication of
the server to the client, which is impossible to receive and forward
(for obvious reasons; you don't want an attacker doing it!).
Mats Lidstrom wrote:
> I've been following this thread for a while and I can't stop
> thinking what about just generate a random number instead of a MAC
> adress? And to be on the safe side just check the server if
> there's an exact number already playing and if so - regenerate it?
The need for an "address" is something fundamental to encrypted
protocols; it can be anything that satisfies the following: If you
do not include something that is explicitly (and un-fakeably)
referential to a particular client, and connection snooping is
possible (as is the case with TCP/IP) you cannot prevent someone
from snooping the connection, recording the client's credentials,
and then spoofing the client (pretending to be the client),
preferably by knocking the client offline for a few minutes, or
waiting for the player to stop playing and yet forgetting to logout.
Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list