Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

Adam Barth <ietf@adambarth.com> Mon, 26 July 2010 10:52 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 873A53A69F0 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 03:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.682
X-Spam-Level:
X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.295, 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 FUxo7f0s54y2 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 03:52:16 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D6D5C3A6A58 for <hybi@ietf.org>; Mon, 26 Jul 2010 03:52:14 -0700 (PDT)
Received: by gxk1 with SMTP id 1so951180gxk.31 for <hybi@ietf.org>; Mon, 26 Jul 2010 03:52:35 -0700 (PDT)
Received: by 10.150.142.3 with SMTP id p3mr9237792ybd.114.1280141554993; Mon, 26 Jul 2010 03:52:34 -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 34sm3577285ibi.6.2010.07.26.03.52.33 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 03:52:33 -0700 (PDT)
Received: by iwn38 with SMTP id 38so2902253iwn.31 for <hybi@ietf.org>; Mon, 26 Jul 2010 03:52:32 -0700 (PDT)
Received: by 10.231.39.134 with SMTP id g6mr8411913ibe.8.1280141551350; Mon, 26 Jul 2010 03:52:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.79.85 with HTTP; Mon, 26 Jul 2010 03:52:10 -0700 (PDT)
In-Reply-To: <25137069-5C6D-4171-873D-65F9925077A8@apple.com>
References: <AANLkTilfxps1wWjFrwrH_3Js6Q9E331AMKFRNHfeHcdL@mail.gmail.com> <AANLkTi=vPAnnK0=gE=YN10vt9b-f6sWXXcwK+La5SriO@mail.gmail.com> <623C6D70-B4AF-49EC-BA07-6F90BD0FFFBF@apple.com> <AANLkTi=Q-PVrdaWuOu3H=wUiphe6JB4C+LauSOXKozoY@mail.gmail.com> <AANLkTi=Z-Zw3gJAdwQMAqG5UUVnV_kgsGm3M_qQ2Bwt7@mail.gmail.com> <8B47440C-7CFD-442F-94E3-96A8EBE7D25D@apple.com> <AANLkTimRo_ubic96z3VgwexiOw0KJg10HQedmcuBs6jp@mail.gmail.com> <FA3856A4-FF29-430E-8BE4-3049F1E33A03@apple.com> <AANLkTim14YJgikfeU9k84xMqtcFt0cdqJQZcsNmvt-Eo@mail.gmail.com> <1453160A-6353-4720-88BA-43D17038B4A7@apple.com> <AANLkTimT+mNXBoQO5L11_ibv645u8Se5K+GBhP9vKXmj@mail.gmail.com> <25137069-5C6D-4171-873D-65F9925077A8@apple.com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 26 Jul 2010 12:52:10 +0200
Message-ID: <AANLkTin1PBskrUYFeOYzexwZOe++WSOCiSRbp6_RDCsh@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Insight you need to know: Browsers are at fault when servers crash
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: Mon, 26 Jul 2010 10:52:18 -0000

On Mon, Jul 26, 2010 at 12:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Jul 26, 2010, at 3:16 AM, Adam Barth wrote:
>> On Mon, Jul 26, 2010 at 11:45 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> On Jul 26, 2010, at 12:39 AM, Adam Barth wrote:
>>>> You can also this this idea at the end
>>>> of an HTTP-like handshake to get started sending data without waiting
>>>> for the server to reply.
>>>
>>> Doesn't this second design make WebSocket services potentially vulnerable to
>>> cross-protocol attacks from HTTP? It's easy for the HTTP attacker to make up
>>> a key and encrypt the attack payload with it, unless the server has to prove
>>> it understands WebSocket based on part of the handshake that the in-browser
>>> HTTP attacker can't control before it is allowed to process messages.
>>
>> I don't quite follow.  You seem to be worried about the WebSocket
>> server being attacked by a non-WebSocket client.  How does that relate
>> to whether a WebSocket client waits for the server to acknowledge?
>
> The current design requires the server to fairly thoroughly validate the handshake before it is even possible for it to process messages. A previous design made it easy for the server to ignore the handshake and just start processing messages. If the key for decoding messages is in the HTTP body, or any part of the request that could plausibly be controlled by an attacker, then we are back to that earlier state where it is much easier to accidentally write a vulnerable server. If the key appears in HTTP headers, then some amount of "rigidity" may be required to make it hard to forge it with a non-WebSocket HTTP request.

Ah, I understand.  We're worried about the consequences of common bugs
in server implementations.  One approach is to use whatever value the
server would have sent back to the client to verify that the server
understood the handshake as part of the key for decrypting the body.
That way the server is forced to do the same computation, we're just
verifying it's correctness cryptographically.

Adam