On Wed, Oct 26, 2011 at 2:09 AM, Tobias Oberstein <[email protected]> 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
