It feels a bit like we are really trying to define what a given "instance" or "version" of an app means. Is it:
a) a static bundle of code authenticated by manifest + signature (or equivalent) b) a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>) c) an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants d) unauthenticated code loaded over any channel, from any origin I'd rough order those from "best" to "awful" on the security spectrum. My 2c is that only a) and b) are viable approaches, though b) is still fraught with risk (the hosting website can still function as a proxy to load terrible code from anywhere). Either of those would be somewhat securable via CSP. In fact we could probably implement a baseline content security policy for apps that ensures some minimum security properties are enforced. I have some experience dealing with this problem set before :) (see https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html) Lucas. On 3/12/2012 11:34 AM, Ian Melven wrote: > adding b2g and webapps lists > > ian > > > ----- Forwarded Message ----- > From: "Ian Melven" <[email protected]> > To: [email protected] > Sent: Monday, March 12, 2012 11:14:50 AM > Subject: Re: [b2g] OpenWebApps/B2G Security model > > > Hi, > > along similar lines, since the current discussion seems to rely heavily on > SSL, > has thought been given to what root certs a B2G device will ship with ? > > will it be the same as the Firefox root store ? personally, i think this > is not a good idea - there are many certs in, for example, the desktop > SSL store that i wouldn't want to trust for the purpose of granting > privileges to apps, or even necessarily authenticating a connection to a > store. > > i assume the vendor/carrier for the device may also want to customize > the root cert store for their devices. > > the current cert pinning proposal > (https://wiki.mozilla.org/Security/Features/CA_pinning_functionality) > assuages some of my concerns - it would be great if the device vendor would > pin the cert of their > own store (and Mozilla did the same for the Mozilla apps store) to > avoid MITM-with-valid-SSL-cert attacks on installs or permission granting. > > just some thoughts. personally i would prefer code signing (helps secure > upgrades, > if we follow Android's model of only an app with the same cert can upgrade an > installed > app) rather than totally relying on SSL - Firefox updates are now signed in > FF12+ as well > as being verified against a hash downloaded over SSL, for defense in depth. > > thanks > ian > > > > ----- Original Message ----- > From: "Kevin Chadwick" <[email protected]> > To: [email protected] > Sent: Monday, March 12, 2012 3:54:53 AM > Subject: Re: [b2g] OpenWebApps/B2G Security model > > On Sun, 11 Mar 2012 21:11:48 -0400 > David Barrera wrote: > >> SSL works well for authentication and as Jonas points out, it is well >> understood by developers and the community. > Actually the whole security community is looking for ways to fix SSL > Google chrome has announced a lookup website. SSL lookup via DNS similar > to DNSSEC has an RFC but record size was a problem (1500 bit RSA limit). > ECDSA keys now given the secure to be used go ahead and being more > secure at a smaller key size (256bit), now make that viable but it > hasn't picked up traction yet. > > That may be a good well tested and RFC'd method similar to DKIM for > email in having a dns record to validate an app is from a domain, it's > easy but may be more difficult for a website to realise how to add TXT > records (dnsmadeeasy.com etc.) than just putting up a website via > Joomla. > > For closed source apps like many on Android, private signing keys are > the only way to go. All you have to trust is your trust in the > developer. Forget the permissions it's good and useful and raises the > bar for an attacker especially when users demand to install apps willy > nilly, but nothing to base real trust on especially with a slow update > mechanism to battle exploits, like on phones. > > For debian you are trusting that their build machines are secure and > the download of the source code secure. They will take methods to > verify the developers keys themselves etc.. and possibly reviewing code. > This eliminates the risk of an author gaining trust through releasing > source code but then offering a trojaned binary. > > A distros build infrastructure also makes it easier for the user > especially when using the primary and more highly reviewed repos but it > is almost a certainty that with the sheer number of packages (> 16GB) in > all of the official Debians repos that there will be some > malware/rootkit in there somewhere. I know I've been too liberal before > and found DDOS trying to go out from a debian box. > > p.s. Of course, I'm not saying don't use SSL for transport > security or domain verification, it is the easiest option for the > masses, but also bear in mind it is likely to be replaced. It's been > said for years but the traction does seem to be increasing against it. > > All these CA problems sure make the loudness of browsers "don't > connect", it has a self signed key rather laughable/annoying. > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
