Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

[Eric Rescorla <[e-mail]>]

On Fri, Nov 26, 2010 at 8:29 PM, Greg Wilkins <[e-mail]> wrote:

>
> On 27 November 2010 12:14, Adam Barth <[e-mail]> wrote:
> >On Fri, Nov 26, 2010 at 4:55 PM, Greg Wilkins <[e-mail]> 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