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

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 26 Oct 2011 02:26:47 -0700
Message-ID: <CAJE5ia8TXMJ16NQJZ8fBVFa5xx8BbDH_LdXetdYhu7PysNnb0w@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Cc: Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>, Simon Pieters <simonp@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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.

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC