Re: Security error when trying to set a non SSL/TLS Websocket from a https page
Hi Nicholas Thanks for bringing this up. I think you bring up an important application scenario that is not at all handled well by the web platform today. everyone happy. Why can't we just whitelist known (or declared secure) WebSocket subprotocols? The idea is simple: a WebSocket connection which is actually encrypted isn't really mixed at all because of the protocol being used. If a 'secure' subprotocol is negotiated, then we're OK to let it through in a mixed context. I disagree. A secure channel is hard to create. As a Firefox user, I only trust my browser to get it right; to disable MD5 when it becomes old; to fix the padding oracle attacks; and [on and on]. To take an extreme case, what stops a site from just using the null cipher and calling it secure (many sites actually do support the null cipher as part of https!). The core problem is: the application author wants to implement a secure channel whereas the browser only trusts its own implementation. I don't know what the solution is: maybe allow insecure XHR and WS if document has CSP turned on with eval/inline-script disabled (thus, no way to convert data to code) thanks dev ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Security error when trying to set a non SSL/TLS Websocket from a https page
The fact of having SSL/TLS inside ws is of course OK for me, that's what I am doing too, but let's say I am against it (which is not the case) I would argue that the issue remains the same: why should it be allowed to work with insecure certificates while SSL/TLS on top of ws don't allow it, and how do you classify a secure subprotocol? I have tried to motivate the Tor fundation about this topic for their flash proxies and ws transport, without success. I still think the current behavior is a serious limitation for ws use that forces you to do insecure things, so the contrary of the intend, but I don't know how to convince Mozilla. Regards, Aymeric Le 04/10/2013 19:07, Nicholas Wilson a écrit : Dear Aymeirc, (public reply for the list) The similar discussion on this list last month about mixed-content websocket connections had the subject Mixed-content XHR Websockets. I have an application which is similar to yours, where the JS does its own crypto using a combination of WebCrypto and emscripten-compiled OpenSSL. (The peers are dynamic and don't have globally-known certificates that a browser's chain-of-trust recognises for TLS, and the webapp has to be served over HTTPS to be secure.) So, we both have a legitimate use of plain (mixed) ws from an HTTPS context. I won't repeat the arguments for mixed-content blocking in Firefox, which is well-documented - Tanvi's blog post is a good place to start (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/) Last month, I proposed a new CORS-style header that would solve our problem in a generic way. I have a new solution this week though, which is less generic and feels a bit bad, but should hopefully make everyone happy. Why can't we just whitelist known (or declared secure) WebSocket subprotocols? The idea is simple: a WebSocket connection which is actually encrypted isn't really mixed at all because of the protocol being used. If a 'secure' subprotocol is negotiated, then we're OK to let it through in a mixed context. I have a spec for this up on github: http://nwilson.github.io/websockets-mixed-context/. I'll post a Firefox patch implementing this soon. I think the next step is going to the appropriate WHATWG list and pestering there? Basically, Firefox is the odd browser out (Chrome doesn't block mixed WebSockets), and Firefox drove the addition of the clause to the spec I'm trying to get tweaked. Is there anyone particularly I should be looking for in Mozilla to review this proposal? Pragmatically, I think it's acceptably small and opens up some cool new webapps that aren't currently possible in Fx. Best, Nicholas - Nicholas Wilson: nicho...@nicholaswilson.me.uk Site and blog: www.nicholaswilson.me.uk 28 St Stephens Place, CB3 0JE 07845 182898 On 23 September 2013 09:21, Aymeric Vitte vitteayme...@gmail.com wrote: Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829 I think I have detailed already in the bug report why it does not necessary make sense to forbid ws from a https page, for your review and comments. Regards, Aymeric -- jCore Email : avi...@jcore.fr Peersm : http://www.peersm.com iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Security error when trying to set a non SSL/TLS Websocket from a https page
Dear Aymeirc, (public reply for the list) The similar discussion on this list last month about mixed-content websocket connections had the subject Mixed-content XHR Websockets. I have an application which is similar to yours, where the JS does its own crypto using a combination of WebCrypto and emscripten-compiled OpenSSL. (The peers are dynamic and don't have globally-known certificates that a browser's chain-of-trust recognises for TLS, and the webapp has to be served over HTTPS to be secure.) So, we both have a legitimate use of plain (mixed) ws from an HTTPS context. I won't repeat the arguments for mixed-content blocking in Firefox, which is well-documented - Tanvi's blog post is a good place to start (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/) Last month, I proposed a new CORS-style header that would solve our problem in a generic way. I have a new solution this week though, which is less generic and feels a bit bad, but should hopefully make everyone happy. Why can't we just whitelist known (or declared secure) WebSocket subprotocols? The idea is simple: a WebSocket connection which is actually encrypted isn't really mixed at all because of the protocol being used. If a 'secure' subprotocol is negotiated, then we're OK to let it through in a mixed context. I have a spec for this up on github: http://nwilson.github.io/websockets-mixed-context/. I'll post a Firefox patch implementing this soon. I think the next step is going to the appropriate WHATWG list and pestering there? Basically, Firefox is the odd browser out (Chrome doesn't block mixed WebSockets), and Firefox drove the addition of the clause to the spec I'm trying to get tweaked. Is there anyone particularly I should be looking for in Mozilla to review this proposal? Pragmatically, I think it's acceptably small and opens up some cool new webapps that aren't currently possible in Fx. Best, Nicholas - Nicholas Wilson: nicho...@nicholaswilson.me.uk Site and blog: www.nicholaswilson.me.uk 28 St Stephens Place, CB3 0JE 07845 182898 On 23 September 2013 09:21, Aymeric Vitte vitteayme...@gmail.com wrote: Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829 I think I have detailed already in the bug report why it does not necessary make sense to forbid ws from a https page, for your review and comments. Regards, Aymeric -- jCore Email : avi...@jcore.fr Peersm : http://www.peersm.com iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Security error when trying to set a non SSL/TLS Websocket from a https page
I don't want to get you started but look: From your own site (!! probably a mistake in the link) https://www.financialcryptography.com/ :-) or https://iang.org/ And maybe when you have time http://www.ianonym.com where it's explained why you might not trust SSL/TLS But I don't want to debate about this, I have answered again to the bug following some questions, showing that Chrome is allowing ws with https and reexplaining why it's not inept to have ws with https in the case you are using a different secure protocol for example. In general I agree that https everywhere should be the standard, but certificates policy inside browser should be more transparent, I have tried for example to push in WebCrypto the feature of exposing certificates, but with no success until now. The problem I see with http allowing https is that you allow the untrusted page to send things that you can potentially not even decrypt, so it's maybe more insecure than using http with https, but again both are insecure, the issue in general is that everything is done to protect the sites, not the users, and things like forbidding ws with https does not enforce necessarly security (I don't understand what you mean exactly by already fixed up the other channel, the fact here is that you connect to routers that can not have a trusted certificate). Regards, Aymeirc Le 24/09/2013 09:38, ianG a écrit : On 23/09/13 12:16 PM, Aymeric Vitte wrote: Le 23/09/2013 10:42, ianG a écrit : And yes, once HTTPS is indicated on the original request, it has to maintain SSL/TLS protection across the lot, otherwise the security claim is broken. That's not the case already, I agree. The situation is that HTTPS-everywhere is becoming the case, and this movement is probably unstoppable. so there should not be an exception for WebSockets. I don't see why there would be any exception for any particular thing, websockets or other? In my case this forces me to use http instead of https to load the main page, and this is of course more insecure. Yes -- in your circumstance, because you've already fixed up the other channel. But the HTTPS model is that we know best and HTTPS is the only and all security. We are kind of stuck in our own hubris on this one; if we want people to move to HTTPS Everywhere, then that's what we have to do. The case of someone not trusting SSL/TLS should be considered too. Mmmph... Don't get me started ... :) While both are insecure this looks to me a non sense to allow insecure http page loading https and not the contrary (or partially) It makes sense to me, in isolation: The http promise is maintained with either http or with https. The https promise is only maintained with https. iang ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Security error when trying to set a non SSL/TLS Websocket from a https page
On 23/09/13 11:21 AM, Aymeric Vitte wrote: Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=917829 I think I have detailed already in the bug report why it does not necessary make sense to forbid ws from a https page, for your review and comments. The problem might be that when you switch across to webservices, there seems no way to say use webservices, but I won't tell you which security level to use. That is, wsa:/ where 'wsa' could mean webserversagnostic, either ws or wss. (fwiw, this is a core flaw in the HTTPS model, that the coder can choose. And yes, once HTTPS is indicated on the original request, it has to maintain SSL/TLS protection across the lot, otherwise the security claim is broken.) iang ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Security error when trying to set a non SSL/TLS Websocket from a https page
Le 23/09/2013 10:42, ianG a écrit : And yes, once HTTPS is indicated on the original request, it has to maintain SSL/TLS protection across the lot, otherwise the security claim is broken. That's not the case already, so there should not be an exception for WebSockets. In my case this forces me to use http instead of https to load the main page, and this is of course more insecure. The case of someone not trusting SSL/TLS should be considered too. While both are insecure this looks to me a non sense to allow insecure http page loading https and not the contrary (or partially) Regards Aymeric -- jCore Email : avi...@jcore.fr Peersm : http://www.peersm.com iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
