Nicholas, I am sure the protocol and encryption you have written is solid and secure. The concern is that once this is opened up, it will be open for all and others won't be so careful. There are lots of examples of people not implementing the crypto correctly.
Re the leaking of sensitive data: browsers already make a practical decision to let some of that data leak by e.g., allowing passive content over HTTP on HTTPS pages (last I checked). I was arguing that once a strong CSP policy is enforced, one can reasonably be certain that arbitrary code won't execute.* In that case, the insecure XHR/WS data can't convert to code (which is presumably the reason it was treated as active content originally) and thus should be treated as passive content and allowed. ~Dev * Well, you can still write a JS interpreter in JS and run arbitrary code. On 10 October 2013 18:38, Nicholas Wilson <nicho...@nicholaswilson.me.uk> wrote: > Devdatta, > > Thanks for your comments. These sorts of concerns about which > implementors users trust can be tricky! The reality is that Firefox > isn't the only person we trust to do crypto right: for a start, you're > trusting every company you give your data to (personal data, credit > card details) to store those securely. You have other applications on > your computer: you trust OpenSSH and numerous other vendors, both > installed on your machine and in the infrastructure that's installed > by your bank, ISP, and others. > > On 10 October 2013 16:16, Devdatta Akhawe <dev.akh...@gmail.com> wrote: >> 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]. > > We're in the position at my company of having a very large number of > enterprise customers (a lot of big tech companies and government IT > departments). They've trusted us for a long time to write a secure > desktop app, and now we want to move that app into the browser, > they'll extend the same trust to us there. > > A secure channel is hard to create, as you say, but the desktop app > developers have working on their protocols and implementations just as > long as browsers have been doing TLS or designing WebRTC. > > I think the big factor is WebCrypto: what was the point of it if the > browsers aren't going to trust JavaScript to actually doing some > meaningful encryption with it? It's an API to expose the same native > crypto primitives the browser itself uses for the benefit of > JavaScript, so that web authors get secure, audited, and updated > implementations of the primitives that are resistant to fiendish > attacks (eg timing attacks) that a JavaScript implementation could > never defend against. As well as getting fast updates to the crypto > primitives by browser vendors, with webapps we'd get immediate updates > of the client software too compared to long upgrade times for > traditional desktop apps we're currently selling. > > Using WebSockets with encryption added using WebCrypto I would have > thought is a pretty canonical use-case for the API! > >> 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) > > So, Devdatta, if we added some extra restrictions would that be enough > to make you happy, like CSP to prevent execution of unsigned content > the browser hasn't verified? That only protects one-way though - it > doesn't do anything to stop sensitive data leaving the page > unencrypted. Ultimately, there's a whole class of webapps that can't > be written unless 1) browsers implement each protocols themselves, the > kitchen sink model, or 2) trust software vendors to run these sorts of > apps in their browsers. > > Even using TLS end-to-end doesn't stop web developers from doing > something stupid and leaving SQL injection attacks wide open. There > comes a point where a webapp or service needs the trust of its users, > because no browser can check what the backend is doing with the data, > anymore than it can verify every single thing the JavaScript is doing. > > I don't think the proposal is asking for the browser to trust site > authors any more than they already do. My proposal uses WebSocket > subprotocols because they're virtually unused at the moment, so the > mixed content blocking is still there for WebSockets except for all > but the most dedicated web authors, who'd have to be writing their own > WebSocket server and backend already too. > > Best, > Nicholas > > ----- > Nicholas Wilson: nicho...@nicholaswilson.me.uk _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
