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

Scott Morgan <> Sat, 01 June 2013 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8479021F9DE5 for <>; Sat, 1 Jun 2013 10:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q+zJIEWnNfNs for <>; Sat, 1 Jun 2013 10:55:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::235]) by (Postfix) with ESMTP id 90D0721F9D24 for <>; Sat, 1 Jun 2013 10:55:39 -0700 (PDT)
Received: by with SMTP id x14so6637345ief.26 for <>; Sat, 01 Jun 2013 10:55:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=0ZODoEFEaaYFGH9lOrbXbmo1N1r773YBMJRK24KmJwk=; b=Mk5wE/5etn51yMhDt8CUuxkaDdtB6/YFqg9DFT4khaHhLidNaIsGh9MST72pcvNBsU Yh1+BRCz6yq2R+W3+aHYAhofhTnAn9Blvc/ydDBkXpeRdiy31n4AMCONp2rBTAg80dWD 95IuApsvKP50ZM+EZM60Z7DDl8MXuyJuLcAwbesF90HKfrTA9BQ9FsHq7XZLxFQYrczc QSGw4uX4tMpVVMvVeWMZD12uTOFzmNC8y3DamGoSU9nX1wfdEnxDHiUK1/sq7W9BmQx3 l22uoDBSK2eJBdTrQVDKLJe2o9RvCo52uwlxoGvdGzeBPL2vmRPLDaGfAHlqyxIma3kN b58A==
MIME-Version: 1.0
X-Received: by with SMTP id bi9mr7140353icc.51.1370109338691; Sat, 01 Jun 2013 10:55:38 -0700 (PDT)
Received: by with HTTP; Sat, 1 Jun 2013 10:55:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 1 Jun 2013 12:55:38 -0500
Message-ID: <>
From: Scott Morgan <>
Content-Type: multipart/alternative; boundary=bcaec51867786fc0cc04de1b70ed
X-Gm-Message-State: ALoCoQnaVJD0pdEkVc4sM4mcld0Q/xviReCmkqXKjO8Mz0VVspEyr5qPNpaNvIoUqVnPzh+0u92o
Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Jun 2013 17:55:40 -0000

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?


  PS see below for other comments if your interested.

On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino <>wrote;wrote:

> On Wed, May 29, 2013 at 4:44 AM, Scott Morgan <> 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.
> 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://
3 Browser connects to url wss://
4 Server checks the ip address of the original https request with the wss
    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.