Re: Security use cases for packaging
On Fri 2015-01-30 01:50:43 -0500, Yan Zhu wrote: 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. I see what you're saying -- and javascript that is directly embedded in the app would all definitely need to be loaded first (since we don't know how it would affect the rest of the application). I was thinking of other resources that might be invoked or loaded later, via XHR or dynamic script load other requests. I suppose the question then arises of what to do if the app triggers an XHR or dynamic script load for a piece of signed content, and that signed content can't be fetched, the entire application would have to block or something to avoid the scenario you describe. That kind of UX doesn't sound very web-like :/ --dkg
Re: Security use cases for packaging
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu y...@yahoo-inc.com wrote:
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.
The application developer could cope with this in the top-layer code:
===
script
var passwordChecker = null;
...
/script
script src=password-checker.js/script
script
if (null == passwordChecker) {
// handle failure of security dependency
}
/script
===
Just as a native application developer should do:
===
void* passwordChecker = dlopen(password-checker.so, ...);
if (NULL == passwordChecker) {
// handle failure of security dependency
}
===
But,
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.
You're probably right, about both web developers and native code developers.
But, if we provide a declarative interface for the package format that
allows developers to declare that a given dependency should be
pre-loaded when possible and mandatorily pre-loaded, they might be
more likely to use that than to write the tedious error-handling code
like that above. I.e. we can create good affordances, and thus get the
benefits of security and performance most of the time.
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
Paging (future Dr.) Deian Stefan to the ER... Any thoughts on using COWL for this kind of thing, with a pinned crypto key as a confinement label to be combined with the regular Origin label? -Brad On Thu Jan 29 2015 at 1:43:05 PM Yan Zhu y...@yahoo-inc.com wrote: 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
But other code from the same origin might not be signed, which could break the security assertion of code signing. The unit of signing should be the same as the unit of isolation, i.e. the origin. Or, the origin should be expanded to include a 4th element, the signing key(s). I don't know how to achieve that in a way that does not bring with it the operational risks (bricking) of HPKP and TACK.
Re: Security use cases for packaging
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. cheers dev
Re: Security use cases for packaging
Brad Hill hillb...@gmail.com writes: Paging (future Dr.) Deian Stefan to the ER... Any thoughts on using COWL for this kind of thing, with a pinned crypto key as a confinement label to be combined with the regular Origin label? Thanks for paging me! I've thought about something like this---providing some form of code integrity---in the context of COWL as well. The idea was to grant a worker the privilege corresponding to the (hash of the) source, in addition to its origin. This would allow a server to verify if the code it is communicating with is trustworthy. (COWL labels are not limited to origins.) I really like Yan's use case. And I think it fits in pretty naturally with COWL: the app, if verification succeeds, can be granted the privilege corresponding to the (hash of the) crypto key: Privilege(https://cryptomail.yahoo.com).and(app-key:...). Other code from the same origin would only have Privilege(https://cryptomail.yahoo.com). I think this may partly address Chris and Dev's concerns. But deciding when not to run the app code is still a question. Though I think the github issue already brings this up. Deian
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
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? [1] http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0008.html On Fri, Jan 30, 2015 at 9:27 AM, Devdatta Akhawe dev.akh...@gmail.com 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. cheers dev
Re: Security use cases for packaging
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 signature.asc Description: PGP signature
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.
Re: Security use cases for packaging
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
