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

From: Scott Morgan <[email-masked]>
Date: Sat, 1 Jun 2013 12:55:38 -0500

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 <[email-masked]>wrote:

> On Wed, May 29, 2013 at 4:44 AM, Scott Morgan <[email-masked]> 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.
>>
>
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 6 Jun 2013 13:18:31 +0900

> On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino <[email-masked]>wrote:
...

> the wss connection if they are NOT, or some other appropriate action)

I see.

>   he gets to transfer money
Sounds fine.

>>>  4 after successful auth message at the browser an the wss connection
>>> is closed

Even without multiplexing, it's possible that both auth and application
traffic come over the same TCP connection. RFC 6455 doesn't prohibit using
the same TCP connection for HTTPS and WSS. It's not about multiplexing but
keep-alive. IIRC, it's still under discussion but technically you can do an
HTTPS for auth and then send WS handshake on the same connection.

---

From: Adam Rice <[email-masked]>
Date: Mon, 10 Jun 2013 16:37:35 +0900

> the wss connection if they are NOT, or some other appropriate action)
It seems to me that storing the session ID in a cookie would make this
easier.

If you want to put the session ID in a URL, I would recommend making it
single-use, although that means you need some mechanism to get a new
session ID if the WebSocket connection fails.

RFC6455 allows WebSocket connections to use a different proxy than HTTPS
connections. Although I'm not aware of any client that actually implements
this, you should not assume that all requests from the same sender will
come from the same IP.

---

From: Scott Morgan <[email-masked]>
Date: Tue, 11 Jun 2013 13:22:03 -0500

On Mon, Jun 10, 2013 at 2:37 AM, Adam Rice <[email-masked]> wrote:

>> 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
Yes it would be easier to implement with a cookie, however it drives me
nuts that cookies are usually used for additional location based
authentication.   For instance, I use a few computers with 3+ user agents
(ie browsers)  each to connect to my bank , and each browser on each
computer needs to have it's cookie verified at a additional level, which
creates extra work for users.

> this, you should not assume that all requests from the same sender will
Could you be a little more specific as to where in RFC6455 it says this?

Also I understand you to mean something like;
Johns FF Browser -> Proxy A https request -> Https/WS Server
Proxy A dies, and Johns internet connection fails over to proxy B
Johns FF Browser ->Proxy B ws request -> WS Server
Is this what you meant?

Cheers,
Scott

---

From: Adam Rice <[email-masked]>
Date: Wed, 12 Jun 2013 11:26:03 +0900

> creates extra work for users.

Personally I usually find the short session timeouts used by banks to be
more aggravating.

I'm not sure what you mean by "location based authentication". I don't want
someone to have access to my account just because they are standing behind
me.

> Could you be a little more specific as to where in RFC6455 it says this?

4.1.3:

       NOTE: Implementations that do not expose explicit UI for
       selecting a proxy for WebSocket connections separate from other
       proxies are encouraged to use a SOCKS5 [RFC1928
<http://tools.ietf.org/html/rfc1928>] proxy for
       WebSocket connections, if available, or failing that, to prefer
       the proxy configured for HTTPS connections over the proxy
       configured for HTTP connections.

> Johns FF Browser ->Proxy B ws request -> WS Server

No, I mean

Johns FF Browser -> Proxy A https request from 1.1.1.1 to HTTPS/WS Server
Johns FF Browser -> Proxy B ws request from 255.255.255.1 to HTTP/WS Server

The proxy is selected based on the protocol, so there is no need to Proxy A
to be dead for Proxy B to be used.

Of course, there are other circumstances where Johns FF Browser might
change IP address, for example when switching between mobile networks.

Thanks,
Adam

---

From: Scott Morgan <[email-masked]>
Date: Thu, 13 Jun 2013 12:18:14 -0500

HI Adam,

   Thanks for your reply it really helped!

To clarify what I meant by "location based authentication"?
I mean three potential things and any combination of them;
A)  The user could be authenticated base on their location (where they are)
using session cookies or their ip address for implementation.

This one could be useful for blocking requests from locations outside of
your building/neighborhood/state/country exc

B) The location (again either by session cookies or ip address) of the user
in addition to other credentials (ie user id, password) is used to
authenticate the user.

This is the one that most banks use to make them more secure than just a
user id/password?

C) The location (again either by session cookies or ip address) of the user
is used to grant additional roles/privileges to the authenticate user
(however they authenticated).

Cheers and thanks again,
Scott