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

On Wed, Oct 26, 2011 at 2:09 AM, Tobias Oberstein
<tobias.oberstein@tavendo.de> wrote:
>> 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

With CORS, XMLHttpRequest is very capable of encountering certificate
errors on third-party origins.

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

They're really all very similar.

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

Usually (in non-attack scenarios) when a server has a self-signed
certificate, all users of the server see the self-signed certificate.
In particular, the developer is likely to find the problem and fix it
by getting a real certificate, which improves security.

Adam

Received on Wednesday, 26 October 2011 09:27:48 UTC