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