Re: [hybi] workability (or otherwise) of HTTP upgrade
Collin Jackson <collin@collinjackson.com> Thu, 09 December 2010 08:37 UTC
Return-Path: <collin.jackson@gmail.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 DDE733A6A94 for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 00:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=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 kOvRecDM60DL for <hybi@core3.amsl.com>; Thu, 9 Dec 2010 00:37:05 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 687E93A6A91 for <hybi@ietf.org>; Thu, 9 Dec 2010 00:37:04 -0800 (PST)
Received: by wyf23 with SMTP id 23so2042510wyf.31 for <hybi@ietf.org>; Thu, 09 Dec 2010 00:38:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=NBzvSNqhKF1oDRWqRUOnSlsSajT7RhCyq5FNTjQ1y9s=; b=LGVwzbQmuUAol1+zQ/KlGkn70RI+SNjp0KcSLpNVbvXwRnh1xa+ZbB2fdeWGx+unbB xn+KxOLGVLdQpjxCNEZMN3AW2v7+bWQW6LS5m85CciYbd9ZKA0QBK10agrQUvr45Zybw RFblnaDACv3fZkN1hm++IKO6ebBdf5KAirJfc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=SHP65oX5Fkrlpj98v8Kp4oQPikjZ+dTluJ8ZL4GivcoyKqC4Tc3enAb5uGKZPjsC7k 1MxGor+CxFjRxZMIuXfOwNlUlE5kVBOld+tem7eMVb7/b7RUvznuIfWvpakiptOkspS5 hKoNGpeZk6lyqMWYogw8a2e4DJZYx5Dw57V50=
Received: by 10.216.155.199 with SMTP id j49mr855072wek.27.1291883912502; Thu, 09 Dec 2010 00:38:32 -0800 (PST)
MIME-Version: 1.0
Sender: collin.jackson@gmail.com
Received: by 10.216.27.202 with HTTP; Thu, 9 Dec 2010 00:38:02 -0800 (PST)
In-Reply-To: <AANLkTik4zgrqqbzWSmuRjS78Ur5ZOeejnP=Zu2usXh6D@mail.gmail.com>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <AANLkTimwiGKdy2eHve9eDezMZg+duuK-AMWpeCR4GH3m@mail.gmail.com> <AB6151A1-A334-469F-BC74-1FA73E6B689A@mnot.net> <221B3DED-A3CC-4961-9CCF-48B6EBCB241F@apple.com> <3605.1291714925.544875@puncture> <AANLkTik4zgrqqbzWSmuRjS78Ur5ZOeejnP=Zu2usXh6D@mail.gmail.com>
From: Collin Jackson <collin@collinjackson.com>
Date: Thu, 09 Dec 2010 00:38:02 -0800
X-Google-Sender-Auth: Fytr4E56i4ZyhttQOl9uSfkb_OQ
Message-ID: <AANLkTi=bDCroNG2yFVebWUAOTDtWgm8mkv9H85nMdDgo@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 09 Dec 2010 01:39:22 -0800
Cc: Server-Initiated HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
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, 09 Dec 2010 08:37:07 -0000
On Sat, 4 Dec 2010 2:50 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote: > So in the POST experiment, the bytes are > > POST /path/of/attackers/choice HTTP/1.1 > Host: host-of-attackers-choice.com > Sec-WebSocket-Key: <connection-key> > > GET /script.php/<random> HTTP/1.1 > Host: target.com > > In 1376 cases the 2nd request was routed to target.com, presumably > because some interceptors parsed it as an HTTP request, and routed it > based on Host. > > In the Upgrade experiment, the bytes are > > GET /path/of/attackers/choice HTTP/1.1 > Host: host-of-attackers-choice.com > Connection: Upgrade > Sec-WebSocket-Key: <connection-key> > Upgrade: WebSocket > > GET /script.php/<random> HTTP/1.1 > Host: target.com > > In only 1 case the 2nd request was routed to target.com. This > experiment is apparently done in the same ad display as the POST > experiment, and the bytes passed over same intermediaries. > > Don't you find that odd? How do you explain the difference? My interpretation is that most (but not all) of the proxies that route requests by Host header decided not to parse the 2nd request as an HTTP request, because they observed an HTTP Upgrade negotiation in the first request. On Sat, 4 Dec 2010 at 3:39 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote: > From paper: "47,741 (96:9%) reported that no intermediaries were > confused when sending the spoofed HTTP request" > > What's the expected behavior here? The 2nd request is transmitted to > host-of-attackers-choice.com verbatim, right? > > "There were 97 of 49;218 impressions (0:2%) where the spoofed request > was routed by IP" > > The 2nd request is also transmitted to host-of-attackers-choice.com > verbatim, right? How does this differ from the 1st case? The 2nd request was received by the server on a separate network connection. On Tue, Dec 7, 2010 at 2:38 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote: > On Tue, Dec 7, 2010 at 3:42 AM, Dave Cridland <dave@cridland.net> wrote: > > On Mon Dec 6 23:27:02 2010, Maciej Stachowiak wrote: > >> > >> I'd like to see more detail on the data than is found in the paper, but it > >> seems to show a real-world hazard with use of Upgrade, since many > >> intermediaries do not understand it and at least a few are confused into > >> treating subsequent traffic as additional HTTP requests and responses. > > > > That's a subtle misread of the paper. > > > > The paper shows that many intermediaries treat any traffic as HTTP requests > > and responses until they find a CONNECT, after which they treat the traffic > > as opaque except in a tiny minority of cases (what, 4 out of 54,000?). > > I do not think the paper corroborates that argument at all. > > Quoting the paper: "In our experiments, we observed two proxies which > appear not to understand CONNECT but simply to treat the request as an > ordinary request and then separately route subsequent requests, with > all routing based on IP address." > > Sounds simple and clear, but let's dig a little deeper. The > experiments sent bytes in the following form (as far as we know, from > conversations on this mailing list) > > CONNECT websocket.invalid:443 HTTP/1.1 > Host: websocket.invalid:443 > Sec-WebSocket-Key: <connection-key> > Sec-WebSocket-Metadata: <metadata> > > GET /script.php/<random> HTTP/1.1 > Host: target.com > > that is, two HTTP requests, well formed. An HTTP interceptor that > understands CONNECT will treat the load(all bytes after the connect > request) as opaque and forward them to the server verbatim. > > On the other hand, a "CONNECT-agnostic" HTTP interceptor, one that > does not "understand CONNECT but simply to treat the request as an > ordinary request and then separately route subsequent requests, with > all routing based on IP address", will do ... pretty much the same > thing! It could have parsed the load into a HTTP request, then sent > the request to the server as is, effectively forwarding the load to > the server verbatim. Neither the client nor the server could detect > the fact that this interceptor parsed the load as HTTP requests. > > Some CONNECT-agnostic interceptors may have touched the 2nd request in > some way, allowing the server to detect them. The two proxies > described in the paper may have done something like that. It would > nice if the authors tell us how exactly they are detected. The 2nd request was transmitted on a separate network connection. That is how we distinguished it from the normal case, which re-uses the initial connection. As discussed in Section V(C)(3) of the paper, we did not observe any caching proxies that had this behavior in our experiment. If these proxies are a concern, it is possible to prevent them from becoming poisoned using encryption. Collin Jackson
- [hybi] workability (or otherwise) of HTTP upgrade Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… Jamie Lokier
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Dave Cridland
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Joe Mason
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Brian McKelvey
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Jack Moffitt
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Collin Jackson
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… SM
- Re: [hybi] workability (or otherwise) of HTTP upg… Pat McManus @Mozilla
- Re: [hybi] workability (or otherwise) of HTTP upg… Scott Ferguson
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Gabriel Montenegro
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Martin J. Dürst
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… James Graham
- Re: [hybi] workability (or otherwise) of HTTP upg… Michael
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu