Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
Eric Rescorla <ekr@rtfm.com> Sat, 27 November 2010 06:15 UTC
Return-Path: <ekr@rtfm.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 C8A853A6B3C for <hybi@core3.amsl.com>; Fri, 26 Nov 2010 22:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 mHaKdp5eZIn1 for <hybi@core3.amsl.com>; Fri, 26 Nov 2010 22:15:41 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DFD783A6831 for <hybi@ietf.org>; Fri, 26 Nov 2010 22:15:40 -0800 (PST)
Received: by gwj17 with SMTP id 17so1380806gwj.31 for <hybi@ietf.org>; Fri, 26 Nov 2010 22:16:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.195.3 with SMTP id x3mr350950agp.16.1290838605530; Fri, 26 Nov 2010 22:16:45 -0800 (PST)
Received: by 10.91.78.6 with HTTP; Fri, 26 Nov 2010 22:16:45 -0800 (PST)
In-Reply-To: <AANLkTikbycTS51Ein9ybbZ52zcrViFCNBjCmpRGD3yCk@mail.gmail.com>
References: <AANLkTim_8g-Cb01si00EkvCK5BtXUx3zHsUee1F6JqsD@mail.gmail.com> <AANLkTimSu1fOGCg0gqX2EFh4v-MkpZuY_-onm3+TO_Z0@mail.gmail.com> <AANLkTimYpdp-75BQSmhAUfyrQv19LvzF1ouznst+ANUG@mail.gmail.com> <AANLkTikbycTS51Ein9ybbZ52zcrViFCNBjCmpRGD3yCk@mail.gmail.com>
Date: Fri, 26 Nov 2010 22:16:45 -0800
Message-ID: <AANLkTim=_Ey_7tSJ0H8OKzip-UcwtJ=YMG5wf_f_qnty@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Greg Wilkins <gregw@webtide.com>
Content-Type: multipart/alternative; boundary="00163676582c8b87fb049602c826"
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: Sat, 27 Nov 2010 06:15:44 -0000
On Fri, Nov 26, 2010 at 8:29 PM, Greg Wilkins <gregw@webtide.com> wrote: > > On 27 November 2010 12:14, Adam Barth <ietf@adambarth.com> wrote: > >On Fri, Nov 26, 2010 at 4:55 PM, Greg Wilkins <gregw@webtide.com> wrote: > >> > >> Was the spoofed HTTP request framed as a websocket frame? > > Nope. It's the handshake's job to establish that it's safe to let the > > attacker to communicate on the socket. > > Adam, > > well I don't want to detract from your findings, which I think are > significant in terms of how intermediaries behave in relation to spoofed > host headers on connections.... but I think that not framing the websocket > content does detract significantly from your findings regarding websocket > handshakes. > > You have shown that unfettered raw access to a socket after an upgrade does > result in significant exploitable vulnerabilities. However, unlike swf or > java, websocket does not propose to give applications unfettered raw access > to the socket. > Well, in every existing proposal, it proposes to give them control over the vast majority of bytes on the socket, with some uncontrollable, but predictable framing. In order for this to be exploitable, you primarily need a proxy which is willing to ignore malformed requests enough to allow the attacker to resynchronize. It's true that we don't have a demonstrated exploit against such a proxy and exactly what's required in order to mount such an exploit is probably somewhat implementation- specific. However, I'm unaware of any convincing security analysis that demonstrates that the framing is a serious obstacle. So by not including the framing (existing or enhanced) you are testing an > artificial situation, finding it vulnerable and exploitable, and then > concluding that websockets is vulnerable and exploitable. I think this is > over stating the case against websockets use of upgrade and ignoring the > proposals already made to protect against this kind of vulnerability. I > think we should also wait to see how the wider problems you have highlighted > are addressed before concluding that Upgrade is fatally flawed (which still > may be the final conclusion). > I don't really understand where you are going with this. Adam's argument throughout the discussion has been that we ought to build a system out of components that are demonstrably secure. To me, that means that the handshake ought to be as secure as we can make it and depend to the minimal amount possible on heuristic arguments about the difficulty of exploiting other pieces of the system. Our measurements indicate that some existing proxies get confused when confronted with the -76 handshake [and it's not clear to me that your proposed handshake will behave any better, since it looks to the proxy like the original -76 handshake followed by a bunch of opaque bytes, which is what the existing -76 handshake looks like. If that doesn't work, then it's likely that the system will just fail.]That leaves us with the primary defense being the difficulty of resynchronizing the framing, which, as I said, depends on assumptions about how error tolerant the proxy is. By contrast, the handshake which Adam and I have described has comparable measured success rates in the field coupled with measurably better (though not provably ideal) in terms of the extent to which it confuses proxies, even without the improved masking we describe in Sectiion V(C)(3). I don't think the relevant question is really--as your message implies--whether the Upgrade handshake is fatally flawed, but rather what the best design is. I think it's pretty clear that the design Adam and I proposed has better arguments for security, so the question is whether there are countervailing factors. As I understand it, your preference for the Upgrade-based handshake is based on the argument that it's more compatible with existing web infrastructure. As far as I can tell, that compatibility is based on two features: (1) the use of a method other than CONNECT. (2) the use of a non-bogus Host header. Your existing proposal abandons aspect #1 in favor of WEBSOCKET, so this leaves us with the non-bogus Host header which is precisely the feature that our study has found to be problematic. Given that, it's not clear to me what the arguments against the CONNECT-based handshake are. Best, -Ekr
- [hybi] Experiment comparing Upgrade and CONNECT h… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Eric Rescorla
- Re: [hybi] Experiment comparing Upgrade and CONNE… Willy Tarreau
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Eric Rescorla
- Re: [hybi] Experiment comparing Upgrade and CONNE… Willy Tarreau
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Ian Fette (イアンフェッティ)
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Willy Tarreau
- Re: [hybi] Experiment comparing Upgrade and CONNE… Scott Ferguson
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Scott Ferguson
- Re: [hybi] Experiment comparing Upgrade and CONNE… Julian Reschke
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Scott Ferguson
- Re: [hybi] Experiment comparing Upgrade and CONNE… Brian
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Joe Mason
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Maciej Stachowiak
- Re: [hybi] Experiment comparing Upgrade and CONNE… Ian Fette (イアンフェッティ)
- Re: [hybi] Experiment comparing Upgrade and CONNE… Zhong Yu
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Willy Tarreau
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Willy Tarreau
- Re: [hybi] Experiment comparing Upgrade and CONNE… Eric Rescorla
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Zhong Yu
- Re: [hybi] Experiment comparing Upgrade and CONNE… Zhong Yu
- Re: [hybi] Experiment comparing Upgrade and CONNE… Maciej Stachowiak
- Re: [hybi] Experiment comparing Upgrade and CONNE… Maciej Stachowiak
- Re: [hybi] Experiment comparing Upgrade and CONNE… John Tamplin
- Re: [hybi] Experiment comparing Upgrade and CONNE… Zhong Yu
- Re: [hybi] Experiment comparing Upgrade and CONNE… Maciej Stachowiak
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Greg Wilkins
- Re: [hybi] Experiment comparing Upgrade and CONNE… Zhong Yu
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Bjoern Hoehrmann
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth
- Re: [hybi] Experiment comparing Upgrade and CONNE… Adam Barth