Security use cases for packaging
Hi all, looking over the W3C TAG packaging draft [1], I would like to see security through package signing as a use case for packaging. A hypothetical scenario using Google/Yahoo's End to End email encryption project: 1. User goes to https://cryptomail.yahoo.com/app.pack for the first time. The HTTP response header includes a package signing key for that resource. This key is pinned, like in HPKP, for some max-age. (The key could also just be included as part of the package.) 2. The browser verifies the signature over app.pack (perhaps as a special signature part in the package body, as in PGP/MIME) using the pinned key for that resource. 3. The packaged app only runs if signature verification succeeds. Verification using the same pinned key is enforced for the max-age amount of time whenever the user loads the package in the future. The context here is that some app authors would like to provide better code integrity guarantees via signing with an offline key. This can be achieved by writing a browser extension or certain types of installable apps, but those have various disadvantages (lack of cross-browser compatibility and dependency on a central app store, for instance). More considerations in the github issue I opened: https://github.com/w3ctag/packaging-on-the-web/issues/21 Thoughts? -Yan [1] https://w3ctag.github.io/packaging-on-the-web/
Re: Security use cases for packaging
chris palmer wrote: But other code from the same origin might not be signed, which could break the security assertion of code signing. Maybe the code from the downloaded package has to be run from a local origin like chrome://*.
Re: Security use cases for packaging
devdatta wrote: Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that model. Whether we achieve this via origins, COWLs, or origin+key as the identifier, is a separate question, but Chris' high level bit remains true. thanks, I meant a unique local (pseudo-)origin assigned to the downloaded package. Chrome extensions derive it purely from the public signing key IIRC; seems like that would suffice here too. ilya wrote: Would it be possible to meet the security goals without assuming that the response body is part of the package? See [1] for background on why that's beneficial.. at least for performance side of the story. I'm picturing a package description where each resource has a SRI token, plus a signature to authenticate the tree of resources / package description itself? A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :(
Re: Security use cases for packaging
packaging and complicated signing is routine for most installable web apps and browser extensions; see https://developer.mozilla.org/en-US/docs/Signing_a_XPI for instance. Developers who build those might actually want the process to be less complicated. Given that the packaging spec lists installable web apps as a use case, it should probably define a signature format. -Yan On Thursday, January 29, 2015 7:12 PM, Michaela Merz michaela.m...@hermetos.com wrote: Pardon my french, but the whole idea is ridiculous. Web development is fluid and flexible. While I most certainly understand the idea and the need for secured loadable code (AFAIK I brought up this issue about 2 months ago), packaging and complicated signing is counter productive. What about external scripts like jquery? Do I really need to download a complete package because I fixed a stupid typo in one of the scripts? Maybe I am completely on the wrong track here (please correct me if I am) - but I think signed code should be handled completely different - thus preserving the flexibility of the LAMP/Script environment as we know it. Michaela On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote: On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. (i haven't developed webapps myself for ages, and the idea of a signed webapp is relatively new to me, so feel free to explain any obvious part that i'm missing) --dkg
Re: Security use cases for packaging
On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote: A signed manifest-like package description that lists the hash and location of every resource seems fine as long as all the resources are downloaded and verified before running the app. Perhaps this kills some of the performance benefits motivating packaging in the first place. :( Why would you need to fetch all the pieces before running the app? Consider a manifest includes an integrity check covering resources X, Y, and Z, but X is the only bit of code that runs first, and Y and Z aren't loaded. If you can validate the manifest, then you know you only run X if you've verified the manifest and X's integrity. If the user triggers an action that requires resource Y, then you fetch it but don't use it unless it matches the integrity check. Say that resource Y is a javascript file that listens for users typing in password fields and shows them a warning if the password is weak. The user verifies and loads the HTML page that includes Y but an attacker then blocks the request to fetch Y, so the user picks a weak password. My intuition is that most developers think about the security of their app as a whole, not the security of their app minus any-given-subset-of-resources.
