[hybi] handshake status

John Tamplin <jat@google.com> Tue, 02 November 2010 21:34 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 A3B583A6A34 for <hybi@core3.amsl.com>; Tue, 2 Nov 2010 14:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.527
X-Spam-Level:
X-Spam-Status: No, score=-100.527 tagged_above=-999 required=5 tests=[AWL=4.850, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, 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 kQ6eB2AYrSgQ for <hybi@core3.amsl.com>; Tue, 2 Nov 2010 14:34:35 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6BD683A6A32 for <hybi@ietf.org>; Tue, 2 Nov 2010 14:34:35 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id oA2LYdAJ028712 for <hybi@ietf.org>; Tue, 2 Nov 2010 14:34:39 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288733680; bh=mWRZ9kpvUnJNTWhZtr9AO/CyE14=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=cNNJckufd/WMSXXZMLaidtSwZ5wgykFo9hE4a+BxWxxk2HqVXdEz8FQ3XZL6aiNX6 Q/AOyKQRBYI1k5K4nbTZw==
Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by hpaq12.eem.corp.google.com with ESMTP id oA2LYbwb005434 for <hybi@ietf.org>; Tue, 2 Nov 2010 14:34:38 -0700
Received: by yxe42 with SMTP id 42so4638026yxe.6 for <hybi@ietf.org>; Tue, 02 Nov 2010 14:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=/zAQTjxBXgFsQr25LqURobRmnj3oWiLI+Pxom7+Pd8w=; b=uFrBJU28CmHK+S7I9CAprzgsPuRlNGwH6cvVYclM/zUYIfdZcYP0jdy8T0TsgsiOSK DdjiXTVRcGCUsh7zld9g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=ImYzfYAW8qkew4vYb4q8B9CyOHXtJjROGVnaawqNeNUVkWAnw/RyHrfyWrugQHRbJH XgtsszqANlt6JIh3GcrQ==
Received: by 10.151.100.3 with SMTP id c3mr10780727ybm.92.1288733677464; Tue, 02 Nov 2010 14:34:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.54.13 with HTTP; Tue, 2 Nov 2010 14:34:17 -0700 (PDT)
From: John Tamplin <jat@google.com>
Date: Tue, 02 Nov 2010 17:34:17 -0400
Message-ID: <AANLkTikJusOZVSgNtzRYsD=VFOVuS-mJ83V9QZzTNeGt@mail.gmail.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
Subject: [hybi] handshake status
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: Tue, 02 Nov 2010 21:34:38 -0000

This email is an attempt to summarize the points of debate over the handshake:

1) the use of GET+Upgrade vs WEBSOCKET vs CONNECT+BogusHost
  - a few concerns with GET+Upgrade:
    - proxies that don't support it may appear to
    - implementations may ignore Upgrade and continue as if it is a
normal HTTP request
    - attacker-controlled bytes in the GET line and the Host header
may be used to attack other protocols
  - concerns about WEBSOCKET method:
    - new method will likely impede interoperability
    - same concern about attacker controlled bytes
  - concerns about CONNECT
    - requires significant changes to current server architectures
    - bogus host address may confuse intermediaries

2) preventing attacker control of bytes in the header
    - current proposal has limited control and likely vulnerabilities
    - Adam's proposal solves this completely, at the expense of
significant complexity and possible problems with intermediaries
    - is allowing attacker controlled bytes totally a show-stopper, or
if we restrict them would that be sufficient?

3) do we need to mask payload bytes
    - doing so could ensure that the client/server both speak WebSockets
    - if not, it is possible that some attacks are enabled, but it isn't clear

If I have missed a significant point on one of these or if there are
other questions about the header, please reply with what should be
added.

We have been talking about this for a while, and I am not sure we are
making any progress.  Some options:

1) go with the current draft approach, knowing it is flawed but also
that it is currently in the wild (as browsers are shipping v76) and is
likely to stay there for at least some time
2) go with Adam's proposal (or at least the basic idea if not the
details) which seems to safely prevent attacks using WebSockets or and
mostly against WebSockets, though at the expense of complexity and
perhaps some interoperability
3) go with some variant of Greg's proposal, which is to make the
GET+Upgrade approach HTTP-compliant and restrict what the attacker can
do but not prevent all possible attacks

I am beginning to wonder if we shouldn't just punt on this in order to
get something deployed, which would be to use a dedicated port and a
dedicated handshake for the first draft, and then we can continue to
work on alternate handshakes (and perhaps TLS/NPN will be a viable
option by that time).  The problem is the longer we wait to define
something, the more entrenched v76 becomes and the less likely our
improvements since v76 will see adoption.

With a dedicated port, we don't have to worry about many of these
problems.  Some deployments of WebSocket servers would just be totally
separate from the HTTP server (which would limit the possibilities for
shared hosting services, at least initially), and others could add
separate infrastructure for receiving and processing WebSocket
connections (which seems like it would be no harder than modifying
them for CONNECT).

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