On Sat, Apr 11, 2015 at 9:25 AM, Jonas Sicking <[email protected]> wrote: > On Thu, Apr 9, 2015 at 1:32 AM, Tim Guan-tin Chien <[email protected]> > wrote: >> The second question we had is whether or not HTTPS+CSP could establish >> the same level of trust. The answer is probably no because of our 300 >> root CAs in NSS and CNNIC, but it is also because HTTPS encrypts and >> signs the streamed files on the fly -- you would not be able to >> establish true accountability between the code executed and the >> certificate without recording the whole HTTPS session. It also deny >> the possibility of 3rd-party reviews before hand. > > Exactly. > >> So the lunch conversation boil down to one question: can we associate >> and sign the resources individually? Either by inserting an >> X-App-Signature in HTTP header or with some signature string in the >> manifest. These ideas sounds utterly familiar to Privileged Hosted >> Apps proposed by the one and only Ben Francis :) but I can't find any >> discussion in written or remember any conversation that prompt us to >> decide on Hosted Packaged App over anything based on the said >> proposal. The conversation in the thread "Proposal: Privileged Hosted >> Apps" doesn't look directing to the proposal directly -- Hosted >> Packaged App does not solve many of the problems raised in that thread >> either (and we may never be able to for problems like creating wall >> gardens). > > This was discussed at the recent workweek. > > The problem with Ben's proposal is that it only gives content > privileges once that content is installed. This because at the time > when we load and execute the HTML/JS, we won't have loaded the > manifest, and the manifest is what contains the signatures, or even > indicates that there are signatures. > > Using a X-App-Signature header would improve that. > > However keep in mind that to have a "signed app", you don't just need > a set of individually signed resources. > > You need to make sure that the the set of resources you have were > signed together. So you don't want to end up with scriptA.js from > version 1 of the app, and scriptB.js from version 2 of the app. That > can be very bad if a security check was moved between the two scripts > between version 1 and version 2. > > You also want to make sure that you have all signed resources that go > along with the app. If an attacker can prevent a given script from > being loaded, that might prevent certain security checks from > happening which cause the app to be exploitable. > > So we need to not just verify each resource, we also need to get some > form of manifest which enumerates all resources that make up a version > of the app, and verify that that manifest is signed. I'm talking here > about manifests in general, and not necessarily the W3C web-manifest. > Though it could of course be the W3C web-manifest. > > And, because we want to make sure we always run only signed code, we > can't allow at least script resources to be modified by the service > worker in order to patch in a delta update to the script. At least not > without somehow ensuring that the resulting resource is can be > verified against a signature which is part of the above mentioned > signing manifest. > > All of this puts some pretty severe limitations on what a service > worker script could do, even if we let the serviceworker handle the > update. I think it'd still qualify as a different update model than > plain service workers. By nature of signing, anything that we do in > this area is going to be different from the "normal web" and quite > unwebby. > > But if someone is willing to put together a proposal which fulfills > all of these requirements I certainly be interested to look. It might > be doable by having the ServiceWorker call some API and pass in the > set of resources that make up the signed app, as well as the signing > manifest. However we'd also have to solve how the signature > verification is done before the service worker is installed, when the > user visits the app the first time. > > Another thing to keep in mind, is that signed content is a *really > small* minority of content that developers will create for FirefoxOS. > A much larger set of content is the normal web. And that is already > quite webby :) > > / Jonas
Thanks for the explanation. :pault also happened to caught me on IRC and speak roughly the same thing: if we are required to sign a version of the app as a whole and the app has to be run as a whole, there isn't much sense to pack the app for review but NOT to deploy it as a package (or, it is more complex to fit the whole app into non-packaged distributed model). My first concern, explicitly, would be the packaged deployment can be more troublesome that we currently foresee. As a web developer, I would like to deploy my content from static hosting like Github Pages or Amazon S3, but in [1] we are looking at server-side solution to deliver a package diff. Compared to a model where content are individually signed, it would indeed ease the logic on client-side but that also means app hosted on static hosting will always be updated with a whole package download. [1] https://wiki.mozilla.org/FirefoxOS/New_security_model#Installing_and_updating The packaged deployment also incidentally make the apps offline-capable. We will likely have people continue to put Firefox OS apps in packages even if they require no extra permissions -- just to get the offline capabilities -- unless we explicitly deny these apps in Marketplace reviews. That would be a unfortunate failure of B2G and bad for the Open Web. If we put the burden of update back to Service Worker or even the old fashioned App Cache, it would indeed be responsible of caching the files, or figure out the files to swap when update, but it would make static hosting possible and make the app delivery return to the same web features. I would imagine there will be some way to update the signature to the new version for a given file w/o re-downloading it. Specifically to your argument on Service Worker will not be able modify the resources: the limitation comes from CSP and all signing solution will not get away from that. We certainly can't verify a script modified by the worker even if the source is from a package. The following however is something need to be figure out, as you pointed out: -- Signature delivery and verifying: page would have to be reloaded if we don't block the loading when verifying the signature. I have no good answer on top of my head yet other than the header or a <meta> tag. -- Integrity: Whether or not fail of getting one file disqualify the app from receiving the privilege. I would say no, as app should safely recover or safely broken in such case, but I would defer to you for security question like this. I might be able to put up something next week. Tim _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
