W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Simplified WebSockets

From: Richard's Hotmail <maher_rj@hotmail.com>
Date: Wed, 29 Oct 2008 17:52:56 +0800
Message-ID: <BAY131-DAV10B12A9CBE694C7C7918A6FB260@phx.gbl>
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@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
> 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
Received on Wednesday, 29 October 2008 02:52:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC