IETF Logo Mail Archive

[hybi] An alternative design for the web socket handshake

Adam Barth <ietf@adambarth.com> Thu, 13 May 2010 19:28 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 6C3723A6A97 for <hybi@core3.amsl.com>; Thu, 13 May 2010 12:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.041
X-Spam-Level:
X-Spam-Status: No, score=0.041 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_50=0.001, 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 tatnNaFYeaty for <hybi@core3.amsl.com>; Thu, 13 May 2010 12:28:37 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 5BF4E3A68F9 for <hybi@ietf.org>; Thu, 13 May 2010 12:26:52 -0700 (PDT)
Received: by pxi19 with SMTP id 19so1035541pxi.31 for <hybi@ietf.org>; Thu, 13 May 2010 12:26:40 -0700 (PDT)
Received: by 10.142.201.17 with SMTP id y17mr6946475wff.283.1273778800129; Thu, 13 May 2010 12:26:40 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id h18sm732880wfg.13.2010.05.13.12.26.38 (version=SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 12:26:38 -0700 (PDT)
Received: by vws13 with SMTP id 13so1495226vws.31 for <hybi@ietf.org>; Thu, 13 May 2010 12:26:37 -0700 (PDT)
Received: by 10.224.71.161 with SMTP id h33mr6583451qaj.161.1273778794119; Thu, 13 May 2010 12:26:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.79.69 with HTTP; Thu, 13 May 2010 12:26:13 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 13 May 2010 12:26:13 -0700
Message-ID: <y2s5c4444771005131226l18de7b18l6d80411890049552@mail.gmail.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [hybi] An alternative design for the web socket handshake
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: Thu, 13 May 2010 19:28:38 -0000

I know there are a lot of pressures on the design of the web socket
protocol, but I thought I would take a few minutes and share my
thoughts on the handshake.  I think bits and pieces of this design
have been proposed by other folks (who I'm failing to credit
properly).

Instead of basing the web socket handshake on HTTP, we should base the
handshake on TLS.  Using TLS gives us better security properties and
more robustness in the face of benign network intermediaries.  Using
TLS has the following important security property:

1) (Security) It is safe to spam TLS connections to arbitrary ports on
arbitrary servers.  (Browsers to this already, so we're either already
screwed or it's ok.)

In particular, we should use the
<http://tools.ietf.org/html/draft-agl-tls-nextprotoneg> extension to
TLS.  Using this extension serves two proposes:

2) (Functionality) Folks can host both their HTTPS server and their
web socket server on the same port (e.g., 443).
3) (Security) We know the receiving server undertands web sockets
because they announced support as part of the TLS handshake.  That
means we don't have to worry about a non-web socket server getting
confused and responding to the web socket handshake.

Finally, using TLS works better with proxies because user agents can
use the CONNECT method of the proxy in the same way we use it today
for HTTPS connections.  This will interoperate with the vast majority
of proxies because the vast majority of proxies accept HTTPS
connections today.

4) (Robustness) Using TLS makes web sockets look like HTTPS to benign
network intermediaries.

Notice that we can still over two kinds of web socket connections (ws
and wss): one that checks the server's certificate and one that
ignores it.  By ignoring the certificate over ws, we make it easy for
hobbyists and small sites to run web socket servers without the need
to purchase a CA-validated certificate.

Adam

v2.23.0 | Report a Bug | By Email