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

Re: WebSocket API: close and error events

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 24 Oct 2011 22:34:10 +0000 (UTC)
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1110242232230.14432@ps20323.dreamhostps.com>
On Mon, 24 Oct 2011, Tobias Oberstein 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.


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


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

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 24 October 2011 22:38:40 GMT

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