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

Reply via email to