[whatwg] Simplified WebSockets

[Richard's Hotmail]

Hi Shannon,

In the absence of Socket Policy Files, this is a good fallback position; the
shorter the handshake, the better.

Cheers Richard Maher

----- Original Message ----- 
From: "Shannon" <shannon at arc.net.au>
To: "WHAT working group" <whatwg at lists.whatwg.org>
Sent: Tuesday, September 30, 2008 4:04 PM
Subject: [whatwg] Simplified WebSockets


> It occurred to me the other day when musing on WebSockets that the
> handshake is more complicated than required to achieve its purpose and
> still allows potential exploits. I'm going to assume for now the purpose
> of the handshake is to:
>
> * Prevent unsafe communication with a non-websocket service.
> * Provide just enough HTTP compatibility to allow proxying and virtual
> hosting.
>
> I think the case has been successfully put that DDOS or command
> injection are possible using IMG tags or existing javascript methods -
> however the counter-argument has been made that the presence of legacy
> issues is not an argument for creating new ones. So with that in mind we
> should implement WebSockets as robustly as we can.
>
> Since we don't at first know what the service is we really need to
> assume that:
>
> * Long strings or certain characters may crash the service.
> * The service may not be line orientated.
> * The service may use binary data for communications, rather than text.
> * Characters outside the ASCII printable range may have special meaning
> (ie, 'bell' or control characters).
> * No string is safe, since the service may use string commands and
> non-whitespace separators.
>
> For the sake of argument we'll assume the existence of a service that
> accepts commands as follows (we'll also assume the service ignores bad
> commands and continues processing):
>
> AUTHENTICATE(user,password);GRANT(user,ALL);DELETE(/some/record);LOGOUT;
>
> To feed this command set to the service via WebSockets we use:
>
> var ws = new
>
WebSocket("http://server:1024/?;AUTHENTICATE(user,password);GRANT(user,ALL);
DELETE(/some/record);LOGOUT;")
>
> I have already verified that none of these characters require escaping
> in URLs. The current proposal is fairly strict about allowed URIs but in
> my opinion it is not strict enough. We really need to verify we are
> talking to a WebSocket service before we start sending anything under
> the control of a malicious author.
>
> Now given the huge variety of non-HTTP sub-systems we'll be talking to I
> don't think a full URL or path is actually a useful part of the
> handshake. What does path mean to a mail server for instance?
>
>
> Here is my proposal:
>
> C = client
> S = service
>
> # First we talk to our proxy, if configured. We know we're talking to a
> proxy because it's set on the client.
>
> C> CONNECT server.example.com:1024 HTTP/1.1
> C> Host: server.example.com:1024
> C> Proxy-Connection: Keep-Alive
> C> Upgrade: WebSocket/1.0
>
> # Without a proxy we send
>
> C> HEAD server.example.com:1024 HTTP/1.1
> C> Host: server.example.com:1024
> C> Connection: Keep-Alive
> C> Upgrade: WebSocket/1.0
>
> # If all goes well the service will respond with:
>
> S> HTTP/1.1 200 OK
> S> Upgrade: WebSocket/1.0
> or
> S> Some other HTTP response (but no Upgrade header)
> or
> S> Other non-HTTP response
> or
> No response.
>
> # If we get a 200 response with Upgrade: WebSocket we *know* we have a
> WebSocket. Any other response and the client can throw a 'Connection
> failed' or 'Timeout' exception.
>
> The client and server can now exchange any authentication tokens, access
> conditions, cookies, etc according to service requirements. eg:
>
> ws.Send( 'referrer=' + window.location + '\r\n' );
> ws.Send( 'channel=' + 'customers' + '\r\n' );
> ws.Send( CookiesToServerSyntax() );
>
> The key advantages of this method are:
>
> * Simplicity (less handshaking, less parsing, fewer requirements)
> * Security (No page author control over initial handshake beyond the
> server name or IP. Removes the risk of command injection via URI.)
> * Compatibility (HTTP compatible. Proxy and Virtual Hosting compatible.
> Allows a CGI script to emulate a WebSocket)
>
> I'm not saying the current proposal doesn't provide some of these
> things, just that I believe this proposal does it better.
>
> Shannon
>
>