W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: AW: WebSocket API: close and error events

From: Simon Pieters <simonp@opera.com>
Date: Tue, 25 Oct 2011 15:13:17 +0200
To: "Ian Hickson" <ian@hixie.ch>, "Tobias Oberstein" <tobias.oberstein@tavendo.de>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <op.v3wscfu8idj3kv@simon-pieterss-macbook.local>
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein  
<tobias.oberstein@tavendo.de> wrote:

>> > Is executing step 2 above (fire "error") meant to cancel execution of  
>> step 3
>> (fire "close")?
>>
>> No, it would say "...and abort these steps" if it did.
>
> Just to be sure I get that right:
>
> If step 2 is executed, that is "error" is fired, then abort and do not  
> continue with step 3, that is do not fire "close"
> If step 2 is not executed, continue and execute step 3, that is fire  
> "close"
>
> ?

No.


>> > Specifically, which events should be fired when WS(S) connection
>> establishment fails due to:
>> >
>> > a) host unreachable (TCP could not even be established)
>> > b) TLS handshake failed (thus TCP was there, but no TLS handshake, and
>> > thus no WS handshake also)
>> > c) TLS handshake failed due to invalid server certificate
>> > d) TLS handshake failed for other reasons (invalid client cert,
>> > non-acceptable ciphers, ..)
>>
>> All of these should be handled identically (for security reasons -- if  
>> we treat
>> them differently you could use it to probe non-WebSocket servers on an
>> intranet, for instance).
>
> Ok, I see. Thats a good reason.
>
>> > Practically, I am mostly interested in:
>> >
>> > How can I detect "TLS failed due to invalid server cert" from
>> > JavaScript in the context of WSS.
>>
>> You cannot, by design. If we allowed JS to detect this it would enable
>> attackers to do network topology scans of restricted networks.
>
> Ok.
>
> Would the following then be appropriate behavior for browsers?
>
> User loads https://somehost.com:9000/index.html
>
> UA presents "cert for somehost:9000 not trusted .. accept .. continue?"  
> dialog.
> => That dialog is builtin, no JS involved. As today.
>
> If user continues, then index.html loads, contains JS.
>
> The JS then opens wss://somehost.com:9090
>
> UA present "cert for somehost:9090 not trusted .. accept .. continue?"
> [*] => Builtin dialog, no JS involved. Not available in browsers today.

I believe Opera does this (if you enable websockets). We might change this  
to reject untrusted certs for websocket, though.


> If user continues, then the WSS connection succeeds. WS onopen() handler  
> fires.
>
> If user does not continue, then WSS connection fails. WS onerror()  
> handler fires - the latter does not give reason for failure.
>
> The JS will get onerror() fired for all reasons a) - d) above.
>
> Thus, there would be not only needed new dialog [*] for "invalid server  
> cert", but also for the other reasons a) - d).
>
> In no case JS involved .. dialogs are browser builtin.
>
> Does above make sense?

No, both error and close fire.

-- 
Simon Pieters
Opera Software
Received on Tuesday, 25 October 2011 13:12:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT