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