On 24 July 2013 17:22, Gervase Markham <[email protected]> wrote: > Have you considered giving the managed servers certs minted from a local > company CA, and trusting that root cert in the copies of Firefox? Or > does that not work either?
Gervase, Thanks for that idea. We did try thinking through all the possibilities here, but none of them is especially attractive. Hopefully this isn't too thorough: 1) The servers have self-signed certs. We can distribute them for the user via our web service, so that when the user tries to make a connection, we download the cert over HTTPS for them and give them some UI leading them through the process of adding it to the trust store for their platform/browser. This isn't great because we'd have to add it to the OS's trust store for Chrome on Windows, for example. We can't clean the cert up when we're done with it, and the user has to go through this process for each and every connection. 2) The servers have certs signed by us. We'd have to run a big operation generating certs for our customers who have millions of machines between them; when they install our software on a new machine (which happens all the time) we'd have to have the server do a CSR that's automatically granted. We just have to trust the node connecting in that it's asking for a cert for an address/hostname it really has because it's going to be behind a corporate firewall. The implication of that is that we still can't leave the crypto up to the browser: we have to do another key exchange and validation in our webapp against the peer's credentials as transferred via our system, because the HTTPS layer isn't protecting against spoofing, it's just there so the browser lets us make a WebSocket. We can't realistically verify the CSRs, we just have to sign basically any and every certificate a customer's install sends us in this model. Another sticky implication is that the cert we manage has to be a CA cert. Whether or not it's per-customer, it's not great to have to ask anyone to put that in the trusted store or their OS or browser, and it's a burden on us to manage that responsibility. 3) We tell customers they need to generate their certs. This frees us of some of the burden, and we still handle distributing the cert via our web service, but it isn't a great model for non-technical users. Other issues: *) We'd need to careful about multi-homed hosts with multiple DNS names or IP addresses. The peer's server probably needs to keep several certs on hand, one for each IP a peer might try and connect with. *) Users simply might not be able to install certs in some environments (Group Policy can lock down the OS cert store that IE/Chrome share). There's another possibility: would a browser ever give a web page an API to install a cert that's valid only for connections from its security context, or specify the cert in a URI perhaps? We could certainly pass the browser something along the lines of "tlscert:sig:xxxxx:uri:wss://192.168.1.1:5800". Via our webservice we could get the peer's expected cert. Even if Firefox implemented this though, it's hardly likely get cross-browser support quickly. I can't give you a patch this at all quickly, and I doubt you want it either. To conclude, this really doesn't feel like the path of least resistance. Our web page knows the peer's identity, we're doing our own crypto for our protocol, and it doesn't feel "webapp-y" to have to save the peer's identity information out of the page and into the browser's global store, when all we want to do is make an outgoing connection from our page to a peer whose identity we know. In this case, TLS is a faff and doesn't feel like a natural fit for peer-to-peer. It doesn't even feel more virtuous to have TLS handle the crypto, when we can call the browser's same OpenSSL RSA and AES routines via the WebCrypto API, but with the added benefit that we know exactly what the peer's RSA pubkey is and can hand it the peer's key in JWK very naturally in our webapp. We can write an appropriate UI for our service, whereas relying on the browser's UI or even the platform cert store is too much out of our control and makes it hard to write a solution that works in all browsers. tl;dr - The web should be a platform for writing network applications that can replace desktop applications with a page in the browser. We have so many of the pieces in place: fast asm.js-formatted JavaScript; WebCrypto in Mozilla and IE11 and Chrome via NaCl; and of course canvas. The only piece we're struggling with is making an outgoing WebSocket connection (in Firefox/IE). We'd rather not be forced down the TLS route and have to delegate our UX to the very varied certificate management across browsers. Thanks for your time. Nick ----- Nicholas Wilson: [email protected] Site and blog: www.nicholaswilson.me.uk 6 Tribune Court, CB4 2TU 07845 182898 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
