Re: [hybi] Fwd: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10

Willy Tarreau <w@1wt.eu> Thu, 21 July 2011 05:57 UTC

Return-Path: <w@1wt.eu>
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 AA1C111E8072 for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 22:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.875
X-Spam-Level:
X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=-3.832, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF9rRsR6gGpw for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 22:57:42 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CA3E011E8071 for <hybi@ietf.org>; Wed, 20 Jul 2011 22:57:41 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6L5vPGP014766; Thu, 21 Jul 2011 07:57:25 +0200
Date: Thu, 21 Jul 2011 07:57:25 +0200
From: Willy Tarreau <w@1wt.eu>
To: John Tamplin <jat@google.com>
Message-ID: <20110721055725.GH13424@1wt.eu>
References: <4E2792EB.2070408@stpeter.im> <CABLsOLCy3xAtXavSGc1mJA18Yhh7gZoaVX9Rg07Dyka1sNx0Tw@mail.gmail.com> <CAP992=ELXXfOevQB7vPP+5-X2D7uPLxmHvHPuNbs36PQsN0aEw@mail.gmail.com> <CABLsOLAY1z19xj5DtBvhN7NmVoeEKyOvWggoFqACC9BTpOBMNA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABLsOLAY1z19xj5DtBvhN7NmVoeEKyOvWggoFqACC9BTpOBMNA@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: rbarnes@bbn.com, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Fwd: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10
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: Thu, 21 Jul 2011 05:57:42 -0000

On Wed, Jul 20, 2011 at 11:57:26PM -0400, John Tamplin wrote:
> On Wed, Jul 20, 2011 at 11:44 PM, David Endicott <dendicott@gmail.com> wrote:
> > Giving me qualms of plausibility.  But I would challenge instead that this
> > is a fault of the intermediaries and not our problem.
> 
> Sure. But the publication of the research led Safari and Firefox to
> disable draft versions of WebSocket in their browsers because they
> didn't want to be on the news for "Browser <xxx> led to an attack on
> <yyy> thousand users ...".
> 
> By the nature of transparent intermediaries, it is hard to discern
> information about them to do anything sensible with vulnerable ones,
> such as disallow WebSocket operation, notify administrators, etc.
> 
> You could say users browsing to sites containing hostile code or
> phishing is the fault of the user and it is their problem, but browser
> vendors still want to help prevent damage to such users.

And with the current masking, even if we don't like it much, at least it
comes at very little cost and serves the purpose quite well.

> > I don't believe anyone suggested raw TCP sockets.    In John's example, he
> > is referring strictly to browser clients.   As a programmer guy, I can write
> > a websocket client in whatever language I want and pretend to be a websocket
> > as polite or malicious as I want.
> 
> Certainly you can write WebSocket clients other than browsers.
> However, most of the security restrictions come about because it is to
> be used by a browser executing potentially hostile code.  If you
> aren't a browser and are running your code directly on the client
> machine, then obviously you can already do whatever you want.

I would also add that in many environments, proxies are configured as
mandatory for browsers. Relying on HTTP ensures that the browser will
use the proxy and not try to scan local networks. And it's the only
way to enable WS connections to be initiated outside via proxies in
those environments.

Willy