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

Maciej Stachowiak <mjs@apple.com> Wed, 29 September 2010 19:32 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 7802A3A6A94 for <hybi@core3.amsl.com>; Wed, 29 Sep 2010 12:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.617
X-Spam-Level:
X-Spam-Status: No, score=-106.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 886BoLtSp1V5 for <hybi@core3.amsl.com>; Wed, 29 Sep 2010 12:32:23 -0700 (PDT)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5B4B43A6DB3 for <hybi@ietf.org>; Wed, 29 Sep 2010 12:32:23 -0700 (PDT)
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 9D798AC03DB9 for <hybi@ietf.org>; Wed, 29 Sep 2010 12:33:06 -0700 (PDT)
X-AuditID: 1180711d-b7b8eae0000035ac-b8-4ca394726b04
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 39.9D.13740.27493AC4; Wed, 29 Sep 2010 12:33:06 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.121.9] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L9I000ZTWZ6DY30@elliott.apple.com> for hybi@ietf.org; Wed, 29 Sep 2010 12:33:06 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <20100929171550.GB8583@1wt.eu>
Date: Wed, 29 Sep 2010 12:33:05 -0700
Message-id: <D82A525D-5F37-4392-AE8A-A5246E5694F3@apple.com>
References: <4CA12810.8020006@caucho.com> <AANLkTimrMfXrnVMjU3f57L_sO7usyYQ56rBM4aMb2Pfr@mail.gmail.com> <20100928052501.GD12373@1wt.eu> <CA8029B0-71A3-44ED-88C6-934FE833BBA2@apple.com> <AANLkTim+fXj-h6OS3OdcfVfh3Q1UwxD8NLVawb=AWHX+@mail.gmail.com> <4FAC5C93-9BDF-4752-AFBC-162D718397AB@apple.com> <AANLkTikcH1W3bQwumqHbe-Yqa3XdoJqCa2b-mZuvoQ7g@mail.gmail.com> <9746E847-DC8B-45A7-ADF3-2ADB9DA7F82E@apple.com> <AANLkTik9igUwoxVrktoBoZrPoUW=Tjh7HyVbGJgQYes-@mail.gmail.com> <9F595226-FA0A-4C38-A6D0-0F4214BD7D21@apple.com> <20100929171550.GB8583@1wt.eu>
To: Willy Tarreau <w@1wt.eu>
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: Wed, 29 Sep 2010 19:32:25 -0000

On Sep 29, 2010, at 10:15 AM, Willy Tarreau wrote:

> On Wed, Sep 29, 2010 at 09:47:37AM -0700, Maciej Stachowiak wrote:
>> 
>> On Sep 29, 2010, at 3:28 AM, Greg Wilkins wrote:
>> 
>>> On 29 September 2010 18:56, Maciej Stachowiak <mjs@apple.com> wrote:
>>>> The raw HTTP request can include a body, which is sent immediately, rather
>>>> than waiting for the remainder of the handshake. The body can include
>>>> content framed as WS protocol messages. A WebSocket client will wait until
>>>> the handshake is complete. So yes, the possibility of attempting an HTTP
>>>> connection to a WebSocket server does create additional attack surface.
>>> 
>>> But how is the HTTP header going to be skipped by the WS server in
>>> order for it to find these encapsulated WS messages?
>>> 
>>> Both a HTTP server and a WS server will consume all of any HTTP
>>> request sent to it, so content will not be mistaken as new messages.
>>> 
>>> It is not sufficient just to send WS frames over the wire.  You have
>>> to explain how they are
>>> going to be sent so that a server will actually read them and
>>> interpret them WS messages.
>> 
>> The idea is that you make an HTTP request with a header that looks close enough to the WS handshake to fool the server, followed by what appear to be WS messages in the body.
> 
> Except that you have the Upgrade header which requires a 101 in
> response. A normal HTTP server will either :
>  - ignore the Upgarde and return a classical code (200, 404, 403, ...)
>  - consider the Upgrade header and either return 101 because it matches
>    the protocol it supports (WebSocket) or return an error code because
>    it does not support the WS protocol.

A standalone WebSocket server may well ignore the presence/absence of the Upgrade header, since performing the rest of the handshake does not depend on it in any way. Since checking it is not technologically required, it's likely some servers won't check it.

Regards,
Maciej