Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

Greg Wilkins <gregw@webtide.com> Sat, 27 November 2010 10:50 UTC

Return-Path: <gregw@webtide.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 91B5F3A6AA7 for <hybi@core3.amsl.com>; Sat, 27 Nov 2010 02:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level:
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 bDsPHcNOWpLt for <hybi@core3.amsl.com>; Sat, 27 Nov 2010 02:50:34 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 767243A6AA4 for <hybi@ietf.org>; Sat, 27 Nov 2010 02:50:34 -0800 (PST)
Received: by wwa36 with SMTP id 36so2880087wwa.13 for <hybi@ietf.org>; Sat, 27 Nov 2010 02:51:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.52.199 with SMTP id e49mr2808413wec.63.1290855098755; Sat, 27 Nov 2010 02:51:38 -0800 (PST)
Received: by 10.216.138.207 with HTTP; Sat, 27 Nov 2010 02:51:38 -0800 (PST)
In-Reply-To: <AANLkTim=_Ey_7tSJ0H8OKzip-UcwtJ=YMG5wf_f_qnty@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> <AANLkTim=_Ey_7tSJ0H8OKzip-UcwtJ=YMG5wf_f_qnty@mail.gmail.com>
Date: Sat, 27 Nov 2010 21:51:38 +1100
Message-ID: <AANLkTim5Bh3vvqr-4g=wDibEU4D32u_jyP8TorUbR_pW@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
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 10:50:35 -0000

On 27 November 2010 17:16, Eric Rescorla <ekr@rtfm.com> wrote:
> I don't really understand where you are going with this.


Eric,

all I'm saying is that the paper has over stated the case against the
websocket upgrade handshake.    It is written as if an exploit has
been found in websocket, when if fact it was an experiment that really
just sent two HTTP requests one after the other, with the first having
Upgrade headers that were ignored.

I think the findings of how some intermediaries are treating the host
headers are indeed a very significant finding, but I don't think it
does the argument any favours to overstate the resulting conclusions.

It may well be that this issue is sufficient to sway us from Upgrade
to Connect, I for one am certainly re-evaluating my position.   But it
is not a slam dunk as it has been presented, as it may be that
framing, flipped bits and HELLO frames may be sufficient to prevent
this vulnerability for the vulnerable intermediaries.


> Our measurements indicate that some existing proxies get confused when
> confronted with the -76 handshake

Was the experiment conducted with the full -76 handshake including the
random bytes after the request and response?  If so were you able to
collect the actual random bytes sent/received to see if they were all
within ASCII range.


> 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.

Indeed this is a thinning defence and I don't dispute that.    But I
do think the paper should acknowledge that this defence does exist.
Over stating the exploit does no favours to the argument against
upgrade.

It well may be that this defence is too thin, but this needs to be
determined by analysis not assumption.  We also need to consider the
defence can be improved or other defences created.
Obviously we also need to consider CONNECT.


> Given that, it's not clear to me what the arguments against the
> CONNECT-based
> handshake are.

Well I've not be talking against the CONNECT based handshake in this
thread.  I've just been enquiring about exactly how websocket-like the
experiment was and expressing a concern that the exploit has been
overstated.  The overstatement is unfortunate as we are now discussing
the overstatement instead of the significant real vulnerability that
was found.

But since you ask, my concern about CONNECT in general is that it may
be limited to ports that it will work for, but that might be the least
of our problems.  My concern about your specific CONNECT proposal is
as you say, about the bogus host headers.

I can't see how the bogus host headers reduce the vulnerability in
this case, because it is the fake host headers in the data stream that
the intermediaries are seeing and resulting in the poisoned caches.
If we made the host header in the upgrade request bogus, I don't think
it would protect against this issue.      I suspect that it is the
CONNECT that is the defence in this case and not the bogus hosts - but
I'll try to find the time to conduct some experiments to check that.