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
