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 Wed, Oct 26, 2011 at 2:09 AM, Tobias Oberstein tobias.oberst...@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
AW: WebSocket API: close and error events
Is executing step 2 above (fire error) meant to cancel execution of step 3 (fire close)? No, it would say ...and abort these steps if it did. Just to be sure I get that right: If step 2 is executed, that is error is fired, then abort and do not continue with step 3, that is do not fire close If step 2 is not executed, continue and execute step 3, that is fire close ? Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). Ok, I see. Thats a good reason. Practically, I am mostly interested in: How can I detect TLS failed due to invalid server cert from JavaScript in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. Ok. 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. 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?
Re: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein tobias.oberst...@tavendo.de wrote: Is executing step 2 above (fire error) meant to cancel execution of step 3 (fire close)? No, it would say ...and abort these steps if it did. Just to be sure I get that right: If step 2 is executed, that is error is fired, then abort and do not continue with step 3, that is do not fire close If step 2 is not executed, continue and execute step 3, that is fire close ? No. Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). Ok, I see. Thats a good reason. Practically, I am mostly interested in: How can I detect TLS failed due to invalid server cert from JavaScript in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. Ok. 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. 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. -- 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.
Re: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein tobias.oberst...@tavendo.de 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: 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: 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. `._.-(,_..'--(,_..'`-.;.'
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch 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, Oct 25, 2011 at 2:34 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch 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, 25 Oct 2011, Glenn Maynard wrote: On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch 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 5:59 PM, Ian Hickson i...@hixie.ch 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:59 PM, Ian Hickson i...@hixie.ch 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 6:32 PM, Ian Hickson i...@hixie.ch 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
