Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

Adam Barth <ietf@adambarth.com> Wed, 01 December 2010 16:59 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 BDF0A3A6BC1 for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 08:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.779
X-Spam-Level:
X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4oEpeu98mNyM for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 08:59:56 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 7660C3A6AAC for <hybi@ietf.org>; Wed, 1 Dec 2010 08:59:56 -0800 (PST)
Received: by yxp4 with SMTP id 4so649681yxp.31 for <hybi@ietf.org>; Wed, 01 Dec 2010 09:01:10 -0800 (PST)
Received: by 10.91.18.33 with SMTP id v33mr1886093agi.153.1291222870010; Wed, 01 Dec 2010 09:01:10 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id i21sm104696yha.44.2010.12.01.09.01.07 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 09:01:08 -0800 (PST)
Received: by iwn40 with SMTP id 40so9037734iwn.31 for <hybi@ietf.org>; Wed, 01 Dec 2010 09:01:06 -0800 (PST)
Received: by 10.231.17.1 with SMTP id q1mr9165828iba.153.1291222866734; Wed, 01 Dec 2010 09:01:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.12.77 with HTTP; Wed, 1 Dec 2010 09:00:35 -0800 (PST)
In-Reply-To: <AANLkTik0wR-Oag5YJJDmdiSy67WW6TMaHmqWEo4o5kGW@mail.gmail.com>
References: <AANLkTik0wR-Oag5YJJDmdiSy67WW6TMaHmqWEo4o5kGW@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 01 Dec 2010 09:00:35 -0800
Message-ID: <AANLkTimwEtKrJm5KxTYZ4wrtONBYDTGjE5LF7__AHBEU@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
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: Wed, 01 Dec 2010 16:59:57 -0000

On Tue, Nov 30, 2010 at 7:33 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> With Upgrade handshake, only 1 (out of 50K) firewall circumvention
> attack was successful. While with POST/Java/Flash, the number is
> around 1000. The Upgrade handshake is a huge improvement! But why? I
> assume that the random bytes and framing bytes in the -76 handshake
> corrupted HTTP streams and busted 99.9% of HTTP parsers.

We're worried about the cache poisoning attacks, not the firewall
circumvention attacks.

> In the singular successful case, the transparent proxy ignored these
> non-http bytes and constructed a http request anyway, at least, it
> extracted the "Host" header. For this attack to be really useful, it's
> not enough that the bytes are tunneled to target.com. The proxy must
> strip non-http bytes and send a compliant http request to target.com.
> Or, the proxy forwards all bytes to target.com, and target server
> strips non-http bytes and reconstructs the intended http request. Did
> one of these two things actually happened in the experiment?

We didn't testing the framing in this experiment, just the handshakes.
 The target server was a stock Apache server.  That means the proxy
forwarded the request in such a form that stock Apache was willing to
respond to it.

> Even worse for the attacker, it's highly unlikely that the http
> response sent back by target.com will be accepted by the WebSocket
> client as valid WebSocket stream. If the attacker cannot read the
> response from target.com, this attack is less useful than sending a
> simple HTTP request.
>
> The combined odds that this attack works over Upgrade handshake is
> extremely small.

Indeed.  That's why we're worried about the cache poisoning attack instead.

> With CONNECT handshake the same transparent proxy did not pass through
> the firewall circumvention attack. It is very likely that the proxy
> routes by Host for each request. The handshake contains an invalid
> Host, the routing failed, the connection was aborted, and the attack
> couldn't be carried out. Most likely CONNECT wins over Upgrade on this
> single case because of the bogus Host header, not because the proxy
> understands CONNECT and gives up parsing the rest of stream.
>
> Altering the semantics of Host is a big deal. Even though it turns out
> to be "helpful" in this singular case of the experiment, the price far
> more exceeds the benefit.
>
> It should be stressed that the paper contains no empirical evidence
> that the bogus Host would be helpful in other threat models.
>
> If Host really is a problem, we should simply remove it from
> handshake. Having no Host header is not worse than having a bogus Host
> header. The Host header was a hack anyway because the request URI
> wasn't absolute. We don't have to keep that hack for WebSocket.
>
> I'm voting for CONNECT method with real Host header.

IMHO, we should adopt the CONNECT handshake first and discuss the
details of what Host header to send second.

> = Inconsistent data regarding cache poisoning attack =
>
> Although the Upgrade handshake reduced firewall circumvention attack
> to 1/1000, it does not have the same luck with cache poisoning attack,
> according to the paper. 50% attacks still got though. That is *very*
> surprising. Caching proxies must demarcate requests precisely, how do
> they have such a higher tolerance of corrupt stream? How come 99.9%
> host-based-routing proxies are busted by the stream, yet 50% of
> ip-based caching proxies are not busted? I must respectfully
> disbelieve the result for now.

I'm not sure where you got the 50% number from.  You're reading the
table incorrectly.  Each of the different handshakes (POST, Upgrade,
and CONNECT) are different experimental conditions (technically
within-subjects conditions).  To understand the data in Table II, you
should read the data vertically, not horizontally.

One way to think about the effectiveness of the cache poisoning attack
is in exploits per dollar.  We show that (without any targeting) an
attacker can achieve 8 exploits for $100, which is concerning.

Adam