On 17/03/12 07:16 AM, Jonas Sicking wrote:
On Wed, Mar 14, 2012 at 2:35 PM, Lucas Adamski<ladam...@mozilla.com> wrote:
My understanding is that there will be multiple app stores. But code signing
has another benefit: reducing systemic risk.
This assume code signing and sane key management, but lets say there's a very
popular app with significant privileges.
To compromise a large number of people, you'd need to:
a) compromise the site hosting the app
b) compromise the key signing the app (assuming you require app updates to be
signed with the same key)
c) compromise or trigger the update mechanism for the app
d) wait for updates to trickle out
This is a tedious process that slows down exploitation, and that's no fun.
If app authentication relies only on SSL, then you just need to pop a web
server (which isn't hard, really). Everyone
using the app gets owned simultaneously.
If we rely on only SSL we still get a), c) and d) AFAICT. Signing only
adds b).
No, if you rely on SSL, you still can't reliably cope with a), c) and
d). As Lucas said, there will be multiple app stores. The attacker
needs to compromise one app store amongst many to cause damage - and the
design isn't settled enough to say that that the user can't do updates
via other stores.
If you look over at the SSL world today - in its post-2011 panic form -
it is exactly the failure mode that has highlighted the weakness of
hierarchical command structures: Compromise one node, compromise the
system.
The other question is, how do you deliver the keys? It would
have to be through some mechanism other than through the web server to
add any level of security.
No, that assumes the attacker is waiting and intercepting every web
server request. In practice, he is not. Otherwise e.g., Firefox
downloads would be infected with MITB on delivery.
It's probably wise not to lean too heavily on the SSL security model.
That model assumed that end-to-end was not important, only
point-to-point was needed. In this model, we are dealing with
potentially very complicated delivery chains. E.g,
developer-supporter-distributer-downloader-local-distributor-end-user
End-to-end security cannot be assumed away in this discussion.
iang
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
