Re: Hello from Mozilla

ons 2009-07-15 klockan 00:51 +0000 skrev Ian Hickson:

> Right -- and those things will prevent the connection, exactly as
> intended. The idea is to make sure that if there is anything in between
> that _isn't_ WebSocket-aware, the connection be dropped before the author
> has any chance of sending data down the pipe. If we didn't do this, then
> it's possible that, e.g., Squid could be tricked into sending data from
> third-party servers in a way that the WebSocket client could not detect,
> thus breaching the same-origin security model.

Which is a clear sign that you MUST NOT use a message that even
resembles a HTTP message for the WebSocket handshake if you don't think
that the HTTP model can accomplish the protocol you need. As all
processing MUST bypass the HTTP stack of the server anyway the message
may in fact look any way you like as long as it can be identified..

But I honestly don't get what you are talking about here. How would
using HTTP Upgrade as intended possibly break the WebSocket security
model?

The WebSocket client has full control over the handshake, and is
responsible for sending it as a well formed HTTP message and also
parsing the HTTP response and should guarantee that it DOES NOT deliver
any non-websocket payload (i.e. 407 responses, 5xx responses etc) to the
WebSocket API user...

> If Squid changes the bytes that are sent from the client or by the server,
> then this bug will likely exist, yes. So don't do that. :-) If a man-in-
> the-middle proxy server modifies the bytes of connections it doesn't fully
> understand, then WebSocket isn't the only thing that will break.

Squid operates on HTTP messages.

While doing so HTTP REQUIRES it to modify the message in certain ways,
and allows it to modify it in several other ways.

- Addition of Via header (MUST)
- Various other informative headers added by Squid. (fully allowed)

But it's not my point. What I said is not even related to Squid but
general protocol design and your design goals with the websocket wire
protocol handshake resembling HTTP.

> (Note that a min-in-the-middle proxy is not the same as a "transparent
> proxy" as defined by the HTTP spec. Per spec, a "transparent proxy" is a
> proxy that does not modify the request or response beyond what is required
> for proxy authentication and identification.)

Err, a semantically transparent proxy still modifies the request in many
ways. Via headers is the most obvious, but there is many many other
small things going on. It's just not allowed to change the request or
response in such way that the request/response means something else.

But yes, a transparently intercepting proxy is a different thing and
what Alex meant.

Regards
Henrik
Received on Wed Jul 15 2009 - 01:48:24 MDT