Re: Proposal: add websocket close codes for "server not found" and/or "too many websockets open"

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