Re: AW: AW: AW: WebSocket API: close and error events
On Wed, Oct 26, 2011 at 2:09 AM, Tobias Oberstein 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
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.
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 6:32 PM, Ian Hickson wrote: > Sure, there are specific cases where one is easier than the other. There > are also specific cases where it's easier to just send malware to the user > than attempt a passive attack. That doesn't mean that we should just > protect against malware and pretend that a passive attack is not a > problem, just like we shouldn't pretend that active attacks are not a > significant risk and thus should allow self-signed certs. > I didn't say any of these things. I said encryption without a trusted signature is not useless. Encryption is always better than no encryption, whether or not you have a trusted certificate. Reducing the safe, undetectable, easily-scalable passive attacks is a significant win. (That doesn't mean the behavior in this particular case is wrong. Adam is almost certainly right: regular users have enough trouble with top-level certificates, and the subresource complication on top of that is probably too much. But please, stop equating unsigned crypto to cleartext.) -- Glenn Maynard
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson wrote: > > > > That only makes sense if passive attack is significantly easier than > > active attack, which it is not. > > Passive attacks are significantly easier to do without any risk of > discovery, especially on a large scale. Sure, there are specific cases where one is easier than the other. There are also specific cases where it's easier to just send malware to the user than attempt a passive attack. That doesn't mean that we should just protect against malware and pretend that a passive attack is not a problem, just like we shouldn't pretend that active attacks are not a significant risk and thus should allow self-signed certs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson wrote: > That only makes sense if passive attack is significantly easier than > active attack, which it is not. > Passive attacks are significantly easier to do without any risk of discovery, especially on a large scale. -- Glenn Maynard
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson wrote: > > On Tue, 25 Oct 2011, Tobias Oberstein wrote: > > > > > > There are situations when self-signed certs are quite common like on > > > private networks or where self-signed certs might be "necessary", > > > like with a software appliance that auto-creates a self-signed cert > > > on first boot (and the user is too lazy / does not have own CA). > > > > A self-signed cert essentially provides you with no security. You > > might as well be not bothering with encryption. > > This is complete nonsense. Protecting against passive attacks is a > major, clear-cut win, even without protecting against active (MITM) > attacks. That only makes sense if passive attack is significantly easier than active attack, which it is not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 2:34 PM, Glenn Maynard wrote: > On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson wrote: >> >> On Tue, 25 Oct 2011, Tobias Oberstein wrote: >> > >> > There are situations when self-signed certs are quite common like on >> > private networks or where self-signed certs might be "necessary", like >> > with a software appliance that auto-creates a self-signed cert on first >> > boot (and the user is too lazy / does not have own CA). >> >> A self-signed cert essentially provides you with no security. You might as >> well be not bothering with encryption. > > This is complete nonsense. Protecting against passive attacks is a major, > clear-cut win, even without protecting against active (MITM) attacks. 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. Protection against passive eavesdroppers isn't worth losing protection against active network attackers. Adam
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson wrote: > On Tue, 25 Oct 2011, Tobias Oberstein wrote: > > > > There are situations when self-signed certs are quite common like on > > private networks or where self-signed certs might be "necessary", like > > with a software appliance that auto-creates a self-signed cert on first > > boot (and the user is too lazy / does not have own CA). > > A self-signed cert essentially provides you with no security. You might as > well be not bothering with encryption. > This is complete nonsense. Protecting against passive attacks is a major, clear-cut win, even without protecting against active (MITM) attacks. -- Glenn Maynard
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Tobias Oberstein wrote: > > There are situations when self-signed certs are quite common like on > private networks or where self-signed certs might be "necessary", like > with a software appliance that auto-creates a self-signed cert on first > boot (and the user is too lazy / does not have own CA). A self-signed cert essentially provides you with no security. You might as well be not bothering with encryption. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
AW: AW: AW: WebSocket API: close and error events
> > Does that mean Opera might just _silently_ reject untrusted certs > > without giving the user a dialog to accept the cert? > > Right. > > > That would be unfortunate IMHO. Since then there is no way to get an > > acceptable user experience any longer. > > > > I can't present a JS created notification and act accordingly, since > > JS won't be allowed to detect "invalid cert". > > > > I can't rely on the browser rendering a builtin dialog for the user to > > accept the cert. > > > > WSS just fails silently. > > > > How is a JS app using WSS supposed to create an acceptable user > > experience? > > By using a cert that isn't rejected. There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be "necessary", like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). The latter is our deployment scenario. We won't ship a fresh key / cert created by an official CA with every appliance. We won't force users to upload such a key/cert before they can use the appliance with https and wss. We need a smooth user experience for users to accept permanently the auto-created self-signed certs for https and wss the appliance uses. We will offer them a way to upload keys/certs when and if they want to. Do you think thats an invalid use case / approach?
Re: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein wrote: > Would the following then be appropriate behavior for browsers? > > User loads https://somehost.com:9000/index.html > > UA presents "cert for somehost:9000 not trusted .. accept .. continue?" > dialog. > => That dialog is builtin, no JS involved. As today. > > If user continues, then index.html loads, contains JS. > > The JS then opens wss://somehost.com:9090 > > UA present "cert for somehost:9090 not trusted .. accept .. continue?" > [*] => Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? Right. That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect "invalid cert". I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? By using a cert that isn't rejected. btw: does Opera support >=Hybi-10, No. -00. and if so, how do I activate it? Enable WebSockets in opera:config. > If user continues, then the WSS connection succeeds. WS onopen() > handler fires. > > If user does not continue, then WSS connection fails. WS onerror() > handler fires - the latter does not give reason for failure. > > The JS will get onerror() fired for all reasons a) - d) above. > > Thus, there would be not only needed new dialog [*] for "invalid > server cert", but also for the other reasons a) - d). > > In no case JS involved .. dialogs are browser builtin. > > Does above make sense? No, both error and close fire. Ok. There are different views on that I guess http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html Seems Richard is misreading the spec. but I - given the comment by Ian, that JS should in no case get detailed error feedback on "invalid cert", whether onclose fires or not - honestly do not care any longer .. it won't solve my problem anyway. OK. On the other hand, I think it should be decided which is the desired behavior: fire onerror only, or fire both. The spec clearly requires both. -- Simon Pieters Opera Software
AW: AW: WebSocket API: close and error events
> > Would the following then be appropriate behavior for browsers? > > > > User loads https://somehost.com:9000/index.html > > > > UA presents "cert for somehost:9000 not trusted .. accept .. continue?" > > dialog. > > => That dialog is builtin, no JS involved. As today. > > > > If user continues, then index.html loads, contains JS. > > > > The JS then opens wss://somehost.com:9090 > > > > UA present "cert for somehost:9090 not trusted .. accept .. continue?" > > [*] => Builtin dialog, no JS involved. Not available in browsers today. > > I believe Opera does this (if you enable websockets). We might change this > to reject untrusted certs for websocket, though. Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect "invalid cert". I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? btw: does Opera support >=Hybi-10, and if so, how do I activate it? > > If user continues, then the WSS connection succeeds. WS onopen() > > handler fires. > > > > If user does not continue, then WSS connection fails. WS onerror() > > handler fires - the latter does not give reason for failure. > > > > The JS will get onerror() fired for all reasons a) - d) above. > > > > Thus, there would be not only needed new dialog [*] for "invalid > > server cert", but also for the other reasons a) - d). > > > > In no case JS involved .. dialogs are browser builtin. > > > > Does above make sense? > > No, both error and close fire. Ok. There are different views on that I guess http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html but I - given the comment by Ian, that JS should in no case get detailed error feedback on "invalid cert", whether onclose fires or not - honestly do not care any longer .. it won't solve my problem anyway. On the other hand, I think it should be decided which is the desired behavior: fire onerror only, or fire both.
