[MUD-Dev] Re: Quick question re: SSL...solution?

[ceo]

Byron Ellacott wrote:
> 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?

> 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.

Indeed I know all this, and have already said all of it. I can't
check the archives to see if I misunderstood someone (last refersh
of archives was 18 feb), but IIRC my last question was in response
to the apparent suggestion that you could use some information "on
the client". Since the client is "any web-browser" the TCP stack
suggestion appeared irrelevant, and my question was partially
rhetorical.

> Unfortunately, the original solution was not any more secure than
> generating a random number as the user's token.  If an attacker A
> is

This is not quite true, although I suppose I must have explained the
correct situation poorly. It *is* secure for all ISP's who don't
intercept the HTTP traffic, because SSL has *built in*
identification, to check that the server claiming to be
"versign.com" is in fact verisign, and not a temporarily hijacked
DNS record...

I always know who the client is, except where they trust a fake
server they shouldn't be trusting (and their web browser ought to be
making sure this doesn't happen). The point here is that if their
account is highjacked in this case it is entirely their fault for
compromising their password - "don't give your password out unless
you are on the correct website!"

The problem is the minority of ISP's amongst my user base who fall
into the situation you describe. In a way, I am still surprised they
are a minority rather than a majority, although I've noticed the
effects when any major ISP has changed their setup :).

> 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.

Thanks. This is the obvious solution I was looking for, and which
I'm now kicking myself for not spotting earlier :). My token was a
shared secret, unexposed to the world during the SSL transaction,
and all I had to do was use it as an encryption key. Doh!

>   [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.

Yes, this was indeed the original setup, otherwise the entirely
secure system wouldn't have been secure at all. The only problem was
that a minority of users were completely shut out of the system,
since they were physically incapable of providing a valid token.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev