AW: AW: AW: AW: WebSocket API: close and error events

> Generally speaking, we don't want to show certificate errors for subresource
> loads (including WebSocket connections) because the user has no context
> for making a reasonable security decision.  For example, Chrome doesn't let
> the user click through certificate errors for images or iframes.

Ok, I see.

However, aren't subresources somehow different? :

1. HTML elements which refer an HTTP addressable resource, like IMG or IFRAME

treating those as "subresources" and not presenting certificate dialogs for each of them
definitely is desirable

2. XMLHttpRequest objects controlled from JS 

same origin policy applies, thus there is no certificate for the XMLHttpRequest done different
from the certificate of the original site serving the JS doing the request

3. WebSocket objects controlled from JS

same origin policy does not apply, the WS server gets the origin, but needs to do its own decision

the target hosts/ports for WS connections embedded in a HTML/JS are designed to and might often
address different hosts/ports than the original serving host

So 3. is somehow different from 2. and 1.

Is it nevertheless agreed consensus that 3. is to be treated like 1. -- like a subresource, and thus
presenting no browser builtin certificate dialog?

==

Just asking .. since if thats the case, we're left with the following situation wrt to self-signed certs and WS:

- browsers won't show dialog because WS is a subresource
- browsers won't give detailed close code to JS, since that would allow to probe the network

JS will get general close code 1006 "abnormal closure" for failed WS connection. That 1006 could be multiple things.

[*] So we can only present a JS rendered dialog: "something went wrong with WS establishment"

We can offer the user to click on a link which takes him to a HTML page rendered by the dedicated WS
server that will render a server status page.

When he does, he then can accept a self-signed cert. Subsequent WS then should succeed.

Dedicated WS server renders the status page when it receives a HTTP/GET without a "upgrade websocket" header.

The [*] is not optimal UX .. but probably acceptable.

Received on Wednesday, 26 October 2011 09:10:29 UTC