Re: [hybi] Extensibility mechanisms?

[Willy Tarreau <[e-mail]>]

Hi Maciej,

On Thu, Jul 22, 2010 at 12:18:19AM -0700, Maciej Stachowiak wrote:
> There's at least three kinds of concerns about cross-protocol attacks and the WebSocket protocol, in the case where the client is the browser:
> 
> 1) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing HTTP resources, if it can make a request that looks sufficiently like HTTP.

Maybe I'm mistaken, but why couldn't such JS code simply make use of the
browser's HTTP client to do so ? Posting a form, reloading an image from
a given URL or making an XMLHttpRequest seems perfectly possible right now,
so trying to do that via the WebSocket code would bring nothing at all.

> 3) Hostile JS code running in the browser may use the browser's HTTP client code (e.g. via XMLHttpRequest) to try to attack newly created WebSocket servers, if it can make a request that looks sufficiently like WebSocket.

The same is true here : why would the JS code try to use the normal HTTP
client if the browser supports WebSocket, with which the code would be
able to have finer control over its attack ?

> > If this is indeed the issue you're talking about, then I don't see why
> > the HTTP-based handshake could be a problem there. It's not more than
> > any other common HTTP request, it's even better in that no data should
> > flow until the server has correctly replied indicating proper support
> > for the protocol.
> 
> What's "the HTTP-based handshake"?

I mean the HTTP Upgrade mechanism.

> We have had several proposals for handshakes that start out looking like HTTP. They are not all equally effective in protecting against cross-protocol attacks, though some of them do have some protection..

Possibly, but what ended up in the spec was finally less secure than the normal
HTTP handshake since it allows the client to send bytes to the server through
reverse proxies without that later being aware of it.

> Although I am not an expert on cross-protocol attacks, one thing I have learned is that the issues can be *extremely* subtle. This leads me to conclude that it's better to err on the side of caution, and design the protocol to be even more robust against such threats than we think is strictly necessary. 

I agree with the *extremely subtle* point. But that's also why I'd rather
not try to reinvent within a small group things that are already efficient
and not proven wrong. We must accept that a small group is never smarter
than those outside the group and that a few hours designs have little
chance of being more robust than those which have survived exposure to the
world for 10 years or so.

It's just like when you see developers implement their own crypto algorithm
because "the public ones have not been broken yet but they're attacked, so
let's be safe and write a new one". The ones I have talked about on this
subject were really convinced their work was better than everything else,
while it was a disaster. That's what I'd prefer we avoid here.

However, enforcing a strict mode of operations based on something which
already works, or as Sal suggested, enforcing a stricter standard is the
right way to go.

> I believe the TLS-based handshake (as proposed by Adam) is more robust than solutions involving nonces and challenge/response built into an HTTP-like handshake. The reason for this is that it's hard for the attacker to control the bytes sent, other than to cause the initiation of a TLS handshake, which is something that all network services are already exposed to by browsers. The attacker cannot get to the next-level protocol running over TLS unless the server explicitly opts in. With HTTP-based schemes, it takes much more care to avoid sending information as the "wrong" protocol.

I agree with those points, but as suggested, there are many cases where
being limited to TLS can be a showstopper, either due to overhead, or
more simply because it will leave many users away (mostly those inside
enterprises who can only access a limited set of SSL sites).

We should spend some time trying to enumerate what aspect(s) of the HTTP-based
handshake we believe may be a problem regardless of the protocol deployed on
the target server.

> However, HTTP-based challenge-response solutions are definitely better than not trying to address the issue at all.

100% agree !

Regards,
Willy