Re: [hybi] Handshake was: The WebSocket protocol issues.

Maciej Stachowiak <mjs@apple.com> Sun, 10 October 2010 03:40 UTC

Return-Path: <mjs@apple.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 E48F13A6405 for <hybi@core3.amsl.com>; Sat, 9 Oct 2010 20:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.169
X-Spam-Level:
X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 iUwznXCrttmc for <hybi@core3.amsl.com>; Sat, 9 Oct 2010 20:40:32 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 0CC7F3A6403 for <hybi@ietf.org>; Sat, 9 Oct 2010 20:40:32 -0700 (PDT)
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 9C331B4F98AC for <hybi@ietf.org>; Sat, 9 Oct 2010 20:41:40 -0700 (PDT)
X-AuditID: 1180711d-b7c86ae000000247-92-4cb135f4ab8f
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id B6.45.00583.4F531BC4; Sat, 9 Oct 2010 20:41:40 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [10.0.1.14] ([69.181.196.33]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LA2002M129FG440@elliott.apple.com> for hybi@ietf.org; Sat, 09 Oct 2010 20:41:40 -0700 (PDT)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTim9JWH15Cc9esL4hCP5cAcK=VvHLU-_9TFe=Gr_@mail.gmail.com>
Date: Sat, 09 Oct 2010 20:41:37 -0700
Message-id: <A16867C7-1F27-4027-BFBF-B13A23B754A5@apple.com>
References: <AANLkTikszM0pVE-0dpZ2kv=i=y5yzS2ekeyZxtz9N=fQ@mail.gmail.com> <AANLkTik9igUwoxVrktoBoZrPoUW=Tjh7HyVbGJgQYes-@mail.gmail.com> <9F595226-FA0A-4C38-A6D0-0F4214BD7D21@apple.com> <4CA4BE10.1010709@caucho.com> <AANLkTi=wKFnNOuM+U3fktAFRn3R5OZ7c6PR2W3EAy7tm@mail.gmail.com> <4CA53E6B.1040808@caucho.com> <AANLkTikOyvF5AHTf4sDD=rWmK2FTD6R6LaHa4KTqkbcm@mail.gmail.com> <4CA68098.8010404@caucho.com> <AANLkTinYhW9MnnM3tkbCWziePyM7mFUEteKhw5OGp-eS@mail.gmail.com> <AANLkTi=_ejOCNiM49VW5q05=H7-M0jzAvXvGaKM1b7mX@mail.gmail.com> <AANLkTimyJj+Jxz1Q6fLrQ8iosGkD+0shUh3=td+jX_Do@mail.gmail.com> <4CA772A1.2090808@caucho.com> <AANLkTi=nLixtxMEd4B58Zp5FRbquNX2C_=7gCf9BGGQs@mail.gmail.com> <4CABCBFA.6020100@caucho.com> <AANLkTi=5wbCXWpOtUQT1MndgCxt9gj6uR_3U=nONpjKc@mail.gmail.com> <4CABD11F.3060500@caucho.com> <AANLkTiksehiSp7DB17MBVBb457p6pN5E8vma6FHz1c9j@mail.gmail.com> <4CACA667.3040309@caucho.com> <4CAF9589.1060007@caucho.com> <AANLkTinnnT5Oib7FvDdZF2q_WUT8=q8KNmfkfajE0Mor@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAA==
Cc: hybi <hybi@ietf.org>
Subject: Re: [hybi] Handshake was: The WebSocket protocol issues.
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: Sun, 10 Oct 2010 03:40:38 -0000

On Oct 9, 2010, at 2:46 PM, Greg Wilkins wrote:

> 
> With regards to my null trial - I agree that such "surveys" (specially
> with a sample size of 1) are not really indicative, only somewhat
> informative.      However, I do think we need to analyse our framing
> from the perspective of could WS frames be mistaken for HTTP requests.

If we encrypt the connection, as in Adam and Eric's proposal, or as suggested earlier by me, then such an analysis is not required. From the attacker's perspective, every frame they send would look like random bytes. It would not be possible to control the bytes to look like an HTTP message. Conversely it would also be impossible to make a chosen HTTP message body look like WebSocket frames.

If the attacker is unable to send specific chosen bytes as a message frame, that is a much stronger defense against cross-protocol attacks than relying on a coincidence of valid message frames not looking like an HTTP request. Or at least, it is easier to have a high degree of confidence in the analysis.

I note in passing that this defense is somewhat independent of whether to use a CONNECT-based or Upgrade-based handshake.

Regards,
Maciej