Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

John Tamplin <jat@google.com> Sun, 28 November 2010 08:03 UTC

Return-Path: <jat@google.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 37A643A6B49 for <hybi@core3.amsl.com>; Sun, 28 Nov 2010 00:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.877
X-Spam-Level:
X-Spam-Status: No, score=-109.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 vhUiQNn7B+gR for <hybi@core3.amsl.com>; Sun, 28 Nov 2010 00:03:18 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 22EDA3A6AEE for <hybi@ietf.org>; Sun, 28 Nov 2010 00:03:17 -0800 (PST)
Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id oAS84Oei014410 for <hybi@ietf.org>; Sun, 28 Nov 2010 00:04:24 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290931464; bh=dbZAkkAtPqKBccosDickFitj1uU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=wZaMNzaxY9nWM1d0MEWEicNuQydTUehRcufmWwu+3xctSWJgf3BZtbnJvP00rVkzk kTfSQOv52QPOU8MI0HfIw==
Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by hpaq13.eem.corp.google.com with ESMTP id oAS84NoK003600 for <hybi@ietf.org>; Sun, 28 Nov 2010 00:04:23 -0800
Received: by yxt3 with SMTP id 3so1230730yxt.5 for <hybi@ietf.org>; Sun, 28 Nov 2010 00:04:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=NMmCi4rw+7+RwdVYfk8VYZrYM5eQjz6OKg7Waeaj4hA=; b=m3trMaOebTBI/kUklTlrw8D5046VquDcMw8GgriI0Ti1oAQu4kFzeVkUt6G7vanw+Y zlIacpT2AAaajVTYGwBg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Ntb2mZXkBzVfwIq+AvE+rA0mJrZxLCjFk1eFWmmZhHKx80yU1Zi3kpk1iJ3Vn+AnxC Y6VvuDTYnYqldEpDBGtw==
Received: by 10.151.143.12 with SMTP id v12mr8313423ybn.35.1290931461780; Sun, 28 Nov 2010 00:04:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.54.13 with HTTP; Sun, 28 Nov 2010 00:04:01 -0800 (PST)
In-Reply-To: <AANLkTikbycTS51Ein9ybbZ52zcrViFCNBjCmpRGD3yCk@mail.gmail.com>
References: <AANLkTim_8g-Cb01si00EkvCK5BtXUx3zHsUee1F6JqsD@mail.gmail.com> <AANLkTimSu1fOGCg0gqX2EFh4v-MkpZuY_-onm3+TO_Z0@mail.gmail.com> <AANLkTimYpdp-75BQSmhAUfyrQv19LvzF1ouznst+ANUG@mail.gmail.com> <AANLkTikbycTS51Ein9ybbZ52zcrViFCNBjCmpRGD3yCk@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Sun, 28 Nov 2010 03:04:01 -0500
Message-ID: <AANLkTi=x5sVSiwkLNq1dgr2Jdi-zQeX0QAQSbFMi5ojH@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
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, 28 Nov 2010 08:03:19 -0000

On Fri, Nov 26, 2010 at 11:29 PM, Greg Wilkins <gregw@webtide.com> wrote:
> One of the reasons expressed that websocket should use framing is that it
> was considered unsafe to have free access to a socket, even after a
> handshake, for reasons like the vulnerability you have highlighted. Framing
> can prevent user supplied content looking like HTTP requests, plus there are
> some proposals that further harden framing against such spoofing.  Also the
> Hello proposal (which does not involved an extra round trip) offers further
> protection.

Note that adding Hello frames or arbitrary other verification that a
real WebSocket client is connecting doesn't help -- in this attack
scenario, the attacker is running their JS code in the browser and
their code on the server, and it sets up a real WebSocket connection.
Unless the payload is masked, you have to rely on the handshake and
framing ensuring that a transparent proxy doesn't accept WebSocket
payload content as if it were an HTTP request.  Also note that since
the attacker controls the server, they can add extra headers to the
Upgrade response which will be ignored by the WebSocket client but may
confuse the transparent proxy.

-- 
John A. Tamplin
Software Engineer (GWT), Google