On Wed, 23 May 2012 06:21:21 +0200, Jason Duell <jduell.mcb...@gmail.com>
wrote:
On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters <sim...@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
