[MUD-Dev] Re: Quick question re: SSL

[Byron Ellacott]

On Thu, 2004-03-04 at 19:55, ceo wrote:
> szii at sziisoft.com wrote:

>> You can get the IP address from the TCP stack on the client.
>> Then you can register "player X is at IP xxx.yyy.zzz.aaa" on the
>> server.  You could also use the socket information (sockaddr_in
>> structure) to determine that information and register it.

> How, exactly, do you do this with HTTP?

If you're writing a CGI application, CGI 1.1 specifies that the
REMOTE_ADDR environment variable should contain the IP address of
the remote host making the request.

If you're writing a program that speaks HTTP over a socket directly,
you're able to record the connecting IP address yourself.

If you're writing an Apache module or equivalent for other servers,
the API for that server should expose the remote IP.

I don't think the question I answered is the question you meant to
ask. I think you wanted to know how to identify the machine that
sourced the request, not the machine who last intercepted it and
forwarded the request to you.  Unfortunately, you do not have this
information in the transport protocol, nor is it guaranteed to be in
the HTTP headers, nor can you trust information in packets that came
from the Internet anyway.

However, the original problem was based around certain (transparent)
proxies changing the source IP address for HTTP, but not for HTTPS.
You wanted a way to verify that the person passing you a token was
the same person you issued that token to, and you could no longer
use remote IP to do that.

Unfortunately, the original solution was not any more secure than
generating a random number as the user's token.  If an attacker A is
able to snoop the traffic between your client C and server S, they
would be able to extract the token, fake a request from C, and read
what S sends back.  If attacker A is unable to snoop the traffic, a
random token is sufficiently secure.

If you're willing to get hacky with Javascript, you can probably do
the following:

  1) During the secure setup, set a cookie on the client containing
  a secret key, randomly generated.

  2) The submit button on each page invokes a piece of javascript
  that performs a hash of the input fields and the secret key.

  3) Your server then compares that hash with its own computation.

The attacker knows the token, the hash, and the hash method used,
but as long as they do not know the secret key they cannot pretend
to be the client.  This rules out both spoofing and man in the
middle[0], so long as your secret keys are not guessable and are not
used for long enough for the attacker to brute force them.

--
bje

  [0] Man in the middle is still possible if the attacker intercepts
  the initial HTTPS connection.  Note that SSL encryption prevents
  snooping, it does not perform authentication.  You should at the
  very least use a server certificate so the client can be certain
  they're talking to the right thing.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev