- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 23 May 2012 08:08:38 +0200
- To: public-webapps@w3.org, "Jason Duell" <jduell.mcbugs@gmail.com>
On Wed, 23 May 2012 06:21:21 +0200, Jason Duell <jduell.mcbugs@gmail.com> wrote: >> On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters <simonp@opera.com> >> wrote: >> >>> 4. If the connection could not be opened, either because a direct >>> connection failed or because any proxy used returned an error, >>> then the client MUST _Fail the WebSocket Connection_ and abort >>> the connection attempt. >>> >>> I'm also wondering if it would be useful to have a dedicated >>> error code for this case ("server not available'). >> >> I believe it would be a security problem to expose to scripts detailed >> reasons about how it failed to connect. > > Could you say more about why a simple "connection not available" would > be a security problem, Simon? Earlier drafts of the WebSocket Protocol had the following requirement (I don't know why it was removed; I stopped following hybi): User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations: o A server whose host name could not be resolved. o A server to which packets could not successfully be routed. o A server that refused the connection on the specified port. o A server that did not complete the opening handshake (e.g. because it was not a WebSocket server). o A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified an origin that differed from the script's). o A WebSocket server that abruptly closed the connection after successfully completing the opening handshake. I believe the problem is related to wanting to not expose information about stuff behind the user's firewall, more than can be exposed with other Web features already. Pre-WebSocket features don't expose "connection not available" vs other reasons for failure, if I'm not mistaken, so WebSocket shouldn't either to be on the safe side. > We already have a code for the special > case of TLS handshake failing: Maybe we shouldn't. (Same argument as above.) > a code that encompasses every other > reason why the connection wasn't made doesn't seem obviously risky to > me (but I'm no security expert).. > >>> Also: I expect every browser that implements web sockets will have >>> some limit on the number of websockets it allows to be open at once >>> (to prevent DoS attacks if nothing else). >> >> >> The spec has a simple measure against DoS -- only allowing one socket in >> the connecting state at a time per host (or some such). But there can be >> platform-specific limitations. > > True, but this doesn't protect against running out of file descriptors > for sockets, etc. Indeed. > So while it's not an easy DoS vector, it's still a > possible scenario. For now, Firefox is calling onerror and onclose > with 1011 in this case ("internal error", though it's a loose > application of the code, since its intended to be sent by the remote > endpoint rather than used for internal errors in the client). I could > probably be persuaded to throw an exception instead--in fact, I'm > almost convincing myself of it as I type :) (We made the decision > not to queue the connection, because WS's are long-lived and there's > thus no obvious wait time bounds). OK. Exception works for me. It would be good if the WebSocket API spec said to throw (and what to throw) for this scenario. > Thanks for the feedback. > > Jason Duell > Mozilla -- Simon Pieters Opera Software
Received on Wednesday, 23 May 2012 06:09:13 UTC