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" <ma1l1i...@yahoo.co.uk> To: dev-security@lists.mozilla.org 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 dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security