The other problem with relying solely on SSL, as i mentioned before, is that it requires trusting the full set of root certificates on the device. This is obviously not a B2G/OWA specific problem but it does seem to be a little worse in this case, ESPECIALLY in hostile environments when the government has or can easily obtain a root cert.
This is why we sign desktop Firefox updates as well as verifying them against a hash downloaded over SSL. Defense in depth. thanks, ian ----- Original Message ----- From: "Lucas Adamski" <[email protected]> To: "Justin Lebar" <[email protected]> Cc: [email protected], [email protected], "Benjamin Smedberg" <[email protected]>, "Ben Francis" <[email protected]>, "Mozilla B2G mailing list" <[email protected]> Sent: Friday, March 16, 2012 11:33:04 AM Subject: Re: [b2g] Scope of B2G applications On Mar 16, 2012, at 10:49 AM, Justin Lebar wrote: >> Yes, clearly OWA was not designed with Gaia apps in mind. To be blunt, my >> opinion at this point is that a model with no code authentication or >> controls on importing code over plaintext channels, is insufficient for a >> privileged application like Gaia. It would leave Gaia apps open to the most >> trivial MITM attacks. >> Lucas. > > I understand the bit about code authentication. If the web server > gets hacked, we're screwed. > > But surely well-functioning Gaia code would only load code over HTTPS, > so I don't understand where this MITM attack comes from. Sure, I think if we believe that all Gaia apps should be loaded over HTTPS then we should just enforce that. Having worked through this problem before, my faith in people voluntarily using HTTPS when necessary is really low. That doesn't address the system risk issue, which is something I'd like to try to figure out. Jim Straus has a proposal in the other thread of including hashes in the manifest, though that would require signing the manifest itself in turn with something that chains to a trusted root… blah blah… blah. Otherwise you're still just relying on HTTPS. Lucas. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
