[hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid)

Adam Barth <ietf@adambarth.com> Mon, 28 March 2011 20:33 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A80CA3A6902 for <hybi@core3.amsl.com>; Mon, 28 Mar 2011 13:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id FmxjdIzrrkE1 for <hybi@core3.amsl.com>; Mon, 28 Mar 2011 13:33:09 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id A4F683A68D2 for <hybi@ietf.org>; Mon, 28 Mar 2011 13:33:09 -0700 (PDT)
Received: by vws12 with SMTP id 12so3075178vws.31 for <hybi@ietf.org>; Mon, 28 Mar 2011 13:34:47 -0700 (PDT)
Received: by with SMTP id zr6mr6118717vdb.6.1301344486922; Mon, 28 Mar 2011 13:34:46 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com []) by mx.google.com with ESMTPS id h18sm2361521vbj.11.2011. (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 13:34:46 -0700 (PDT)
Received: by qwg5 with SMTP id 5so2562658qwg.31 for <hybi@ietf.org>; Mon, 28 Mar 2011 13:34:45 -0700 (PDT)
Received: by with SMTP id fa2mr3819190qab.364.1301344485228; Mon, 28 Mar 2011 13:34:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 28 Mar 2011 13:34:14 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 28 Mar 2011 13:34:14 -0700
Message-ID: <BANLkTi=0a84PA+2hN9U7S9uvNWgmestE2g@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid)
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, 28 Mar 2011 20:33:10 -0000

On Mon, Mar 28, 2011 at 6:32 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> On 3/28/11 1:29 AM, Greg Wilkins wrote:
>> Firstly, I actually don't think we can prohibit non-101 responses.  We
>> have consensus that  before the 101 the handshake must be HTTP
>> compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant
>> responses that will very likely be seen no matter what we say here.
> I basically agree with this - I would put it even stronger. Before the 101
> this is HTTP and therefore the ietf websockets draft really doesn't have
> much to say other than what is already covered by HTTP. HTTP says if the
> response is 101 then start doing the upgraded protocol, otherwise this is
> still HTTP. The draft could use some clarification here.

The WebSocket protocol is a profile of HTTP.  WebSockets is free to
define as small a profile as we choose.  In particular, we're free to
close the connection on non-101 status codes.

> Personally I think to be successful UA's are going to need to implement
> 401s, redirects to pages that set cookies based on closed algorithms (and
> then probably redirect again), etc... Whether or not a UA chooses to chase a
> redirect (or prompt for auth, or whatever) is, as always, up to them.

I'm skeptical of this claim.  I believe we can implement quite
successful user agents permitting only the 101 status.

> Adam, I'm interested in specific classes vulnerabilities you see there. Even
> in generalities. They might be arpopos for the security considerations
> section.

Let's focus on redirects for a bit because those are some of the most
problematic.  Redirects introduce significant complexity in HTTP.  For
example, redirects have been responsible for a large number of
security vulnerabilities in Firefox (and every other browser).  By
introducing redirects into the WebSockets protocol, we're forcing
developers using WebSockets to deal with their complexities, and
they're going to screw it up.

Consider the following code:

var url = <obtain URL from somewhere, e.g. postMessage>

if (!url.startsWith("wss://example.com/"))

var socket = new WebSocket(url);
socket.onopen = function () {
  [... interact with socket ...]

Reading this code, it's quite natural to assume that sending and
receiving information on socket will actually communicate with
example.com.  For example, I might send confidential information to
example.com or rely upon the integrity of information received from
example.com.  However, if example.com has has an open redirector (as
is extremely common on the Internet), this assumption is incorrect and
leads to vulnerabilities.

Now, we can wring our hands and claim that this sort of issue isn't
our problem, but it is.  Simply warning folks about these traps in
Security Considerations is just passing the buck.  Instead, we
shouldn't add this complexity to WebSockets at this time.  We can
always change out minds and add support for redirects in the future,
but we can never remove support once added.