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
