On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein
<[email protected]> 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
