Re: [hybi] hybi Digest, Vol 51, Issue 14

[Scott Morgan <[e-mail]>]

Hi Takeshi,

   Your link to the rfc answered most of my questions, sorry I am new to
the commenting process.    I am trying to use the ip address header of
multiple connections to provide a bit more validation of the ip address
header, since mux may always use the same physical connection it would
always have the same ip address header.
    I realize this is probably the wrong place to ask the following
question but;
Is anyone aware of another or better way to validate the source ip address
of a TCP/IP connection?

Thanks,
Scott

  PS see below for other comments if your interested.


On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino <[e-mail]>wrote:

> On Wed, May 29, 2013 at 4:44 AM, Scott Morgan <[e-mail]> wrote:
>
>>     Also what will happen if multiple to the multiplexed ws if one of
>> two browser tabs calls close on the ws connection?
>>    Does the other tab force keep the ws connection open?
>>    Does the other tab have to auto recover and reopen the connection?
>>
>
> close() call on a WebSocket instance that is multiplexed in network stack
> should result in close of the logical channel used by the WebSocket
> instance. Not close on the physical WebSocket connection. Once the last
> logical connection is closed, the network stack may start closing the
> physical connection. It can be also delayed.
> http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-10#section-15 is
> the section discussing that.
>
>
>> Sorry if I missed this somewhere in the drafts.
>> Just my 2cents.
>>
>>    It's important for a attempt to block browser ip address spoofing on
>> the first ws connection in a the following use case;
>>
>>
> Could you elaborate?
>
Yes and actually I am going to change the way I do this after reading the
rfc.   I am going to use regular http(s) for the authentication part so
this would change to the following.

1 Browser sends authentication to the server over https
2 Server notes the ip address of the request and responds with a ws url to
the client if successful ie.  wss://example.com/valid?session=123
3 Browser connects to url wss://example.com/valid?session=123
4 Server checks the ip address of the original https request with the wss
connection
    to make sure they are the same, and takes appropriate action (closes
the wss connection if they are NOT, or some other appropriate action)




>
>
>> 1 Browser connects to a wss server
>> 2 User does some authentication (ie user id, password)
>> 3 wss server does authentication using user id, password and ip address
>> (for either some privileges or as a additional authentication parameter
>> for a success fail style authentication)
>>
>
> That is that only access from some IP address X will have some high
> privilege?
>
Yes the ip address of the user may allow the user to gain additional
privileges, ie something like;
John logs in to the Bank from a public computer he can't do much, but see
the accounts.
John logs in from his office (and the office ips addresses are marked as
secure locations)
  he gets to transfer money

Note my application is not a bank application, this is just a example.

>
>
>>  4 after successful auth message at the browser an the wss connection is
>> closed
>>  and a different wss is opened on the same port with a different path in
>> the url
>> 5 The wss server only allows the different wss connection to open if
>> there is a http session from the original wss connection from the same ip
>> address of the first connection.
>>
>
> Does the server get a session parameter over the new connection and also
> check the source IP address? Or the server here just checks if there was
> successful authentication on some prior connection with the same IP address
> as the new one?
>
My main goal was to attempt to validate the IP address of the sender by
comparing the ip address of multiple connections, (originally both wss, now
https and wss).


>
>
>>
>> Not that this is a fool proof solution to ip address spoofing, but it
>> would at least provide some level of ip address spoofing support (as the
>> spoofer would need to know that it had to spoof twice).  If the connection
>> stayed open, the original spoof would remain in effect and this sort of
>> attempt to block ip address spoofing would be rendered completely
>> in-effective.
>>
>
>