AW: WebSocket API: close and error events

> > 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"

?

> > 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.

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?

Received on Tuesday, 25 October 2011 08:49:37 UTC