Re: [hybi] CONNECT handshake text

Greg Wilkins <gregw@webtide.com> Wed, 08 December 2010 09:12 UTC

Return-Path: <gregw@intalio.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 91F5A3A693A for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 01:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.282
X-Spam-Level:
X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1]
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 0ZXAH3v89xKG for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 01:12:35 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6E4EC3A6930 for <hybi@ietf.org>; Wed, 8 Dec 2010 01:12:34 -0800 (PST)
Received: by qwg5 with SMTP id 5so1077497qwg.31 for <hybi@ietf.org>; Wed, 08 Dec 2010 01:14:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.67.17 with SMTP id p17mr6718219qai.382.1291799639731; Wed, 08 Dec 2010 01:13:59 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.167.203 with HTTP; Wed, 8 Dec 2010 01:13:59 -0800 (PST)
In-Reply-To: <AANLkTikEMwkY9G2RXjTrX+Uf97kvyfmm2Qi5CdK=_Cr+@mail.gmail.com>
References: <AANLkTinEXHBeaUPo4gK2CHbq7ZHYnY2PE3Vb+Oi+K1NM@mail.gmail.com> <AANLkTimgrC2nehYE=Dnt11naKRY55nMzn=zTmzx+AYpH@mail.gmail.com> <AANLkTik4QUxMVTt=NTMq-Wo7GhOX3ie=eHQRMHZ8fEqd@mail.gmail.com> <AANLkTikEMwkY9G2RXjTrX+Uf97kvyfmm2Qi5CdK=_Cr+@mail.gmail.com>
Date: Wed, 08 Dec 2010 10:13:59 +0100
X-Google-Sender-Auth: 5k1_IlAsAxVEK-mgf8D0CFZKLSU
Message-ID: <AANLkTiknHq_hmdErypdydOpZpRk1y+DQm7aZh1qej3Ao@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Adam Barth <ietf@adambarth.com>
Content-Type: multipart/mixed; boundary="0015175cd688a5afe70496e28a1f"
Cc: hybi@ietf.org
Subject: Re: [hybi] CONNECT handshake text
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: Wed, 08 Dec 2010 09:12:43 -0000

2010/12/7 Adam Barth <ietf@adambarth.com>:
> Unmasking the Host header has some security risk.  The scenario we're
> worried about is one in which the attacker and the target server are
> virtually hosted on the same machine.  In that case, a machine that
> does not understand the Host header is likely to route the request
> according to the Host header, but not understand that it is
> establishing a bidirectional tunnel.  Another approach to mitigating
> this threat is to mask the payload data so the attacker won't be able
> to trick the machine after the handshake completes.

Adam,

is the following description the attack vector that you are concerned about:

www.innocentbystander.com and www.drevil.com are virtually hosted on
the same machine

A client loads some of drevil's javascript that makes a WS connection
to www.drevil.com, which is routed to that virtual host and the WS
connection is accepted.    www.drevil.com and/or the drevil javascript
then send WS packets that contain spoof HTTP requests that are sent to
www.innocentbystander.com   allowing the attacker to bypass same
origin rules etc.


If the server hosting these domains is WS aware, then this is not a problem.
If the server is not WS aware, then we have to ensure that the
handshake is not something that can be accepted by a normal HTTP
server, no matter what application the drevil is running.

The Hello frames that I have proposed protect against this kind of
attack, because they are bytes that an application running on a
non-websocket-aware server cannot generate, thus they cannot trick the
client into accepting the WS connection and sending more bytes.

Also robust WS framing is another layer of defence as it would protect
any packets sent by the client from easily being interpreted as HTTP.

Thus regardless of using CONNECT of Get+Upgrade,  I believe my
proposals for Hello frames and inverting some bits the header are good
defences to include.   I've attached my proposed text/diff for them
again... please feel free to swap out Upgrade for CONNECT if that is
your preference.

regards