Re: [hybi] Extensibility mechanisms?

Adam Barth <ietf@adambarth.com> Thu, 22 July 2010 00:39 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743A93A6987 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwbssOfyKMg3 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 17:39:46 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 760203A6972 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:39:46 -0700 (PDT)
Received: by iwn38 with SMTP id 38so8004907iwn.31 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:40:03 -0700 (PDT)
Received: by 10.231.193.81 with SMTP id dt17mr758744ibb.177.1279759202921; Wed, 21 Jul 2010 17:40:02 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id h8sm29245457ibk.21.2010.07.21.17.40.01 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 17:40:02 -0700 (PDT)
Received: by iwn38 with SMTP id 38so8004891iwn.31 for <hybi@ietf.org>; Wed, 21 Jul 2010 17:40:01 -0700 (PDT)
Received: by 10.231.157.143 with SMTP id b15mr959866ibx.113.1279759201138; Wed, 21 Jul 2010 17:40:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.145 with HTTP; Wed, 21 Jul 2010 17:39:41 -0700 (PDT)
In-Reply-To: <4C479130.4020500@caucho.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de> <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com> <Pine.LNX.4.64.1007202204270.7242@ps20323.dreamhostps.com> <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com> <4C479130.4020500@caucho.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 21 Jul 2010 17:39:41 -0700
Message-ID: <AANLkTikLDjBP-Xs5t6TxmJuq4nG8jwThQ=n34B4cEmup@mail.gmail.com>
To: Scott Ferguson <ferg@caucho.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Jul 2010 00:39:47 -0000

On Wed, Jul 21, 2010 at 5:30 PM, Scott Ferguson <ferg@caucho.com> wrote:
> The counterproposal at
>
>  http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html
>
> not complicated at all: it's a trivial protocol, and yet it solves the HyBi
> requirements, including requirements that the current draft ignores, as well
> as being extensible to muxing requirements.
>
> A dozen members of this list could come up with proposals as simple as that
> one and most would improve on it.

This protocol is highly insecure.  First, the server offers no proof
that it understands the protocol, so it's very likely that it's
vulnerable to cross-protocol attacks.  Second, the client doesn't even
require the server to respond at all before sending (almost) arbitrary
content over the socket, which is very likely to lead to disaster.

Adam