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

Takeshi Yoshino <tyoshino@google.com> Wed, 29 May 2013 03:37 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCEA21F8749 for <hybi@ietfa.amsl.com>; Tue, 28 May 2013 20:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level:
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiSJ0zhc3wrJ for <hybi@ietfa.amsl.com>; Tue, 28 May 2013 20:37:06 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id C45CD21F8681 for <hybi@ietf.org>; Tue, 28 May 2013 20:37:05 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id z11so6082422wgg.19 for <hybi@ietf.org>; Tue, 28 May 2013 20:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=caDwCC+I5aLN9jPvJV+a6+qUYnBrj4HuPnry4Zgyh7s=; b=lE0KP4p1K8Dm1Gfik1kRyHl+ahMbPEcWofSn5c4HjAOPUTYf81E89epcUC+ZbBCEqo pxP0PQ5umuJ24n0cCdedAbMy6YhmSRiLu2vVepBowS6CC/4OUKFRiVRj5krkIGXfXO7z B9q2aQgduZM5EkewNEkE16CTVzIVkiOct9scWpJuWOZFo0MNlev0bu7DCRwwrceNih9b MpsgLjYJl2MJ4Hi4CJauUP+oS/qlUnHytLTLJ1jDB3OuCxZ0FNm/nPAJokS7Ar64zVzI n/1FsYA244N92faeQSV4s8PNGBED1hLpOZgmIVJzduebeWEpWo+uUuK19ISjctoLMMaZ r4fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=caDwCC+I5aLN9jPvJV+a6+qUYnBrj4HuPnry4Zgyh7s=; b=G/3eJ5o/C6NyJZ4GJ2BsOfJfmRdMuPBbzaIMXqpLVeVM0+gtjPwPPzzS1kUhxODKDl 41dcx2CYyPVg8cuL6xMgRb9mt2euvnSkOEE6HCLyZA91B1EXogl8zxr0/vb2BtCPO2v5 l57mNMt8XaSb2l8fOlc3V1pWgTSHrporMjwr70WsykCcWop9LalneTo2zWClsZpz6iLk fYTRi8XQZckzpIH5BfJ+52dzClfRxTrTQsmYHi2hYq9anpptWK5YoHrofhBX0t/4dOFo Ch04zGRhhoNQ/WlJnS1ju2a4d+tPcB70koRffas5/YqEmXxs+Md68jWcXMz1GrLYOAEj GN+w==
X-Received: by 10.180.11.176 with SMTP id r16mr500546wib.58.1369798624746; Tue, 28 May 2013 20:37:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.5.136 with HTTP; Tue, 28 May 2013 20:36:44 -0700 (PDT)
In-Reply-To: <CANEdHmgDD4OCQf009FijtEjU=LzhLoNLZHvXsBxgROmzAyR4+w@mail.gmail.com>
References: <mailman.3.1369767603.10801.hybi@ietf.org> <CANEdHmgDD4OCQf009FijtEjU=LzhLoNLZHvXsBxgROmzAyR4+w@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Wed, 29 May 2013 12:36:44 +0900
Message-ID: <CAH9hSJYfhnmCOF7a9uovsYLObqdXwop35JB6r3PscFwfeO=R=g@mail.gmail.com>
To: Scott Morgan <scott@adligo.com>
Content-Type: multipart/alternative; boundary=001a11c222027138dc04ddd3181a
X-Gm-Message-State: ALoCoQkp0Y9Q/MDtsdP3HBtv0tmzBXklF/B3aWDhuV3LbYDhyvrc1ybCkk+AAJKbPSmiPFW+XZVsmcWd640yBLCtMFt+uLtzVLfy7sLFm1uWRMU1B83J9IWVwbRp0y7HuUH7cfWmyfgdau8c79L7JXolTNEoI/tUnkkUKLJWiwj3TXWIhzw712ID1rxJwHZFnt7JYSWx4AsQ
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 03:37:06 -0000

On Wed, May 29, 2013 at 4:44 AM, Scott Morgan <scott@adligo.com> 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?


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


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


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