Re: What I am missing
Thank you Jonas. I was actually thinking about the security model of FirefoxOS or Android apps. We write powerful webapps nowadays. And with webapps I mean regular web pages with a lot of script/html5 functionality. The browsers are fast enough to do a variety of things: from running a linux kernel, to playing dos-games, doing crypto, decoding and streaming mp3. I understand a browser to be an operating system on top of an operating system. But the need to protect the user is a problem if you want to go beyond what is possible today. I am asking to consider a model, where a signed script package notifies a user about is origin and signer and even may ask the user for special permissions like direct file system access or raw networking sockets or anything else that would, for safety reasons, not be possible today. The browser would remember the origin ip and the signature of the script package and would re-ask for permission if something changes. It would refuse to run if the signature isn't valid or expired. It wouldn't change a thing in regard to updates. You would just have to re-sign your code before you make it available. I used to work a lot with java applets (signed and un-signed) in the old days, I am working with android apps today. Signing is just another step in the work chain. Signed code is the missing last element in the CSP - TLS environment . Let's make the browser into something that can truly be seen as an alternative operating system on top of an operating system. Michaela On 11/19/2014 08:33 AM, Jonas Sicking wrote: On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html. In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. The way we did script signing back then was nutty in several ways. The signing we do in FirefoxOS is *much* simpler. Simple enough that no one has complained about the complexity that it has added to Gecko. Sadly enhanced security models that use signing by a trusted party inherently looses a lot of the advantages of the web. It means that you can't publish a new version of you website by simply uploading files to your webserver whenever you want. And it means that you can't generate the script and markup that make up your website dynamically on your webserver. So I'm by no means arguing that FirefoxOS has the problem of signing solved. Unfortunately no one has been able to solve the problem of how to grant web content access to capabilities like raw TCP or UDP sockets in order to access legacy hardware and protocols, or how to get read/write acccess to your photo library in order to build a photo manager, without relying on signing. Which has meant that the web so far is unable to compete with native in those areas. / Jonas
Re: What I am missing
How the browsers can be code servers? Could you please explain a little more... On 19-Nov-2014 7:51 pm, Michaela Merz michaela.m...@hermetos.com wrote: Thank you Jonas. I was actually thinking about the security model of FirefoxOS or Android apps. We write powerful webapps nowadays. And with webapps I mean regular web pages with a lot of script/html5 functionality. The browsers are fast enough to do a variety of things: from running a linux kernel, to playing dos-games, doing crypto, decoding and streaming mp3. I understand a browser to be an operating system on top of an operating system. But the need to protect the user is a problem if you want to go beyond what is possible today. I am asking to consider a model, where a signed script package notifies a user about is origin and signer and even may ask the user for special permissions like direct file system access or raw networking sockets or anything else that would, for safety reasons, not be possible today. The browser would remember the origin ip and the signature of the script package and would re-ask for permission if something changes. It would refuse to run if the signature isn't valid or expired. It wouldn't change a thing in regard to updates. You would just have to re-sign your code before you make it available. I used to work a lot with java applets (signed and un-signed) in the old days, I am working with android apps today. Signing is just another step in the work chain. Signed code is the missing last element in the CSP - TLS environment . Let's make the browser into something that can truly be seen as an alternative operating system on top of an operating system. Michaela On 11/19/2014 08:33 AM, Jonas Sicking wrote: On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html . In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. The way we did script signing back then was nutty in several ways. The signing we do in FirefoxOS is *much* simpler. Simple enough that no one has complained about the complexity that it has added to Gecko. Sadly enhanced security models that use signing by a trusted party inherently looses a lot of the advantages of the web. It means that you can't publish a new version of you website by simply uploading files to your webserver whenever you want. And it means that you can't generate the script and markup that make up your website dynamically on your webserver. So I'm by no means arguing that FirefoxOS has the problem of signing solved. Unfortunately no one has been able to solve the problem of how to grant web content access to capabilities like raw TCP or UDP sockets in order to access legacy hardware and protocols, or how to get read/write acccess to your photo library in order to build a photo manager, without relying on signing. Which has meant that the web so far is unable to compete with native in those areas. / Jonas
Re: What I am missing
Perfect is the enemy of good. I understand the principles and problems of cryptography. And in the same way we rely on TLS and its security model today we would be able to put some trust into the same architecture for signing script. FYI: Here's how signing works for java applets: You need to get a software signing key from a CA who will do some form of verification in regard to your organization. You use that key to sign you code package. Will this forever prevent the spread of malware ? Of course not. Yes - you can distribute malware if you get somebodies signing key into your possession or even buy a signature key and sign your malware yourself. But as long as the user is made aware of the fact that the code has the permission to access the file system, he can decide for himself if he wants to allow that or not. Much in the same way that he decides to download a possibly malicious peace of software today. There will never be absolute security - especially not for users who give a damn about what they are doing. Should that prevent us from continuing the evolution of the web environment? We might as well kill ourselves because we are afraid to die ;) One last thing: Most Android malware was spread on systems, where owners disabled the security of the system .. eg by rooting the devices. Michaela Suppose you get a piece of signed content, over whatever way it was delivered. Suppose also that this content you got has the ability to read all your private data, or reformat your machine. So it's basically about trust. You need to establish a secure channel of communication to obtain a public key that matches a signature, in such a way that an attackers attempt to self-sign malicious content is foiled. And you need to have a way to discover (after having established that the entity is the one who was intended and that the signature is correct), that you indeed trust that entity. These are two very old problems in cryptography, and they cannot be solved by cryptography. There are various approaches to this problem in use today: * TLS and its web of trust: The basic idea being that there is a hierarchy of signatories. It works like this. An entity provides a certificate for the connection, signing it with their private key. Since you cannot establish a connection without a public key that matches the private key, verifying the certificate is easy. This entity in turn, refers to another entity which provided the signature for that private key. They refer to another one, and so forth, until you arrive at the root. You implicitly trust root. This works, but it has some flaws. At the edge of the web, people are not allowed to self-sign, so they obtain their (pricey) key from the next tier up. But the next tier up can't go and bother the next tier up everytime they need to provide a new set of keys to the edge. So they get blanket permission to self-sign, implying that it's possible for the next tier up to establish and maintain a trust relationship to them. As is easily demonstratable, this can, and often does, go wrong, where some CA gets compromised. This is always bad news to whomever obtained a certificate from them, because now a malicious party can pass themselves off as them. * App-stores and trust royalty: This is really easy to describe, the app store you obtain something from signs the content, and you trust the app-store, and therefore you trust the content. This can, and often does go wrong, as android/iOS malware amply demonstrates. TSL cannot work perfectly, because it is built on implied trust along the chain, and this can get compromised. App-stores cannot work perfectly because the ability to review content is quickly exceeded by the flood of content. Even if app-stores where provided with the full source, they would have no time to perform a proper review, and so time and time again malware slips trough the net. You can have a technical solution for signing, and you still haven't solved any bit of how to trust a piece of content. About the only way that'd be remotely feasible is if you piggyback on an existing implementation of a trust mechanism/transport security layer, to deliver the signature. For instance, many websites that allow you to d/l an executable provide you with a checksum of the content. The idea being that if the page is served up over TLS, then you've established that the checksum is delivered by the entity, which is also supposed to deliver the content. However, this has a hidden trust model that established trust without a technical solution. It means a user assumes he trusts that website, because he arrived there on his own volition. The same cannot be said about side-channel delivered pieces of content that composit into a larger whole (like signed scripts). For instance, assume you'd have a script file (like say the twitter
Re: What I am missing
I am not sure if I understand your question. Browsers can't be code servers at least not today. Michaela On 11/19/2014 08:43 AM, Pradeep Kumar wrote: How the browsers can be code servers? Could you please explain a little more... On 19-Nov-2014 7:51 pm, Michaela Merz michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote: Thank you Jonas. I was actually thinking about the security model of FirefoxOS or Android apps. We write powerful webapps nowadays. And with webapps I mean regular web pages with a lot of script/html5 functionality. The browsers are fast enough to do a variety of things: from running a linux kernel, to playing dos-games, doing crypto, decoding and streaming mp3. I understand a browser to be an operating system on top of an operating system. But the need to protect the user is a problem if you want to go beyond what is possible today. I am asking to consider a model, where a signed script package notifies a user about is origin and signer and even may ask the user for special permissions like direct file system access or raw networking sockets or anything else that would, for safety reasons, not be possible today. The browser would remember the origin ip and the signature of the script package and would re-ask for permission if something changes. It would refuse to run if the signature isn't valid or expired. It wouldn't change a thing in regard to updates. You would just have to re-sign your code before you make it available. I used to work a lot with java applets (signed and un-signed) in the old days, I am working with android apps today. Signing is just another step in the work chain. Signed code is the missing last element in the CSP - TLS environment . Let's make the browser into something that can truly be seen as an alternative operating system on top of an operating system. Michaela On 11/19/2014 08:33 AM, Jonas Sicking wrote: On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html. In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. The way we did script signing back then was nutty in several ways. The signing we do in FirefoxOS is *much* simpler. Simple enough that no one has complained about the complexity that it has added to Gecko. Sadly enhanced security models that use signing by a trusted party inherently looses a lot of the advantages of the web. It means that you can't publish a new version of you website by simply uploading files to your webserver whenever you want. And it means that you can't generate the script and markup that make up your website dynamically on your webserver. So I'm by no means arguing that FirefoxOS has the problem of signing solved. Unfortunately no one has been able to solve the problem of how to grant web content access to capabilities like raw TCP or UDP sockets in order to access legacy hardware and protocols, or how to get read/write acccess to your photo library in order to build a photo manager, without relying on signing. Which has meant that the web so far is unable to compete with native in those areas. / Jonas
Re: What I am missing
That is relevant and also not so. Because Java applets silently grant access to a out of sandbox functionality if signed. This is not what I am proposing. I am suggesting a model in which the sandbox model remains intact and users need to explicitly agree to access that would otherwise be prohibited. Michaela On 11/19/2014 12:01 AM, Jeffrey Walton wrote: On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Seems relevant: Java’s Losing Security Legacy, http://threatpost.com/javas-losing-security-legacy and Don't Sign that Applet!, https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. Dormann advises don't sign so that the code can't escape its sandbox and it stays restricted (malware regularly signs to do so).
Re: What I am missing
Even today, browsers ask for permission for geolocation, local storage, camera etc... How it is different from current scenario? On 19-Nov-2014 8:35 pm, Michaela Merz michaela.m...@hermetos.com wrote: That is relevant and also not so. Because Java applets silently grant access to a out of sandbox functionality if signed. This is not what I am proposing. I am suggesting a model in which the sandbox model remains intact and users need to explicitly agree to access that would otherwise be prohibited. Michaela On 11/19/2014 12:01 AM, Jeffrey Walton wrote: On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Seems relevant: Java's Losing Security Legacy, http://threatpost.com/javas-losing-security-legacy and Don't Sign that Applet!, https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. Dormann advises don't sign so that the code can't escape its sandbox and it stays restricted (malware regularly signs to do so).
Re: What I am missing
On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz michaela.m...@hermetos.com wrote: I don't disagree. But what is wrong with the notion of introducing an _additional_ layer of certification? Adding an additional layer of centralization. -- https://annevankesteren.nl/
Re: What I am missing
First: You don't have to sign your code. Second: We rely on centralization for TLS as well. Third: Third-party verification can be done within the community itself (https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web) . Michaela On 11/19/2014 09:41 AM, Anne van Kesteren wrote: On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz michaela.m...@hermetos.com wrote: I don't disagree. But what is wrong with the notion of introducing an _additional_ layer of certification? Adding an additional layer of centralization.
Re: What I am missing
Browser signature checking gives you nothing that CSP doesn't as far as the security of pages composed from a mixture of content from different providers. As Florian points out, signing only establishes provenance, not any interesting security properties. I can always write a page that runs an interpreter on data loaded from a third-party source even if that data is not loaded as script, so a signed application is always open to confused deputy problems. Signing is a red herring which distracts from the real problem : the envelope model in which secrets are scoped to the whole content of the envelope, makes it hard to decompose a document into multiple trust domains that reflect the fact that the document is really composed of content with multiple different provenances. By the envelope model, I mean the assumption that the user-agent receives a document and a wrapper, and makes trust decisions for the whole of the document based on the content of the wrapper. The envelope does all of 1. establishing a trust domain, the origin 2. bundles secrets, usually in cookies and headers 3. bundles content, possibly from multiple sources. Ideally our protocols would be written in such a way that secrets can be scoped to content with a way to allow nesting without inheritance. This can be kludged on top of iframes, but only at the cost of a lot of engineering effort. On Wed, Nov 19, 2014 at 10:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: I don't disagree. But what is wrong with the notion of introducing an _additional_ layer of certification? Signed script and/or html would most certainly make it way harder to de-face a website or sneak malicious code into an environment. I strongly believe that just for this reason alone, we should think about signed content - even without additional potentially unsafe functionality. Michaela On 11/19/2014 09:21 AM, Pradeep Kumar wrote: Michaela, As Josh said earlier, signing the code (somehow) will not enhance security. It will open doors for more threats. It's better and more open, transparent and in sync with the spirit of open web to give the control to end user and not making them to relax today on behalf of other signing authorities. On 19-Nov-2014 8:44 pm, Michaela Merz michaela.m...@hermetos.com wrote: You are correct. But all those services are (thankfully) sand boxed or read only. In order to make a browser into something even more useful, you have to relax these security rules a bit. And IMHO that *should* require signed code - in addition to the users consent. Michaela On 11/19/2014 09:09 AM, Pradeep Kumar wrote: Even today, browsers ask for permission for geolocation, local storage, camera etc... How it is different from current scenario? On 19-Nov-2014 8:35 pm, Michaela Merz michaela.m...@hermetos.com wrote: That is relevant and also not so. Because Java applets silently grant access to a out of sandbox functionality if signed. This is not what I am proposing. I am suggesting a model in which the sandbox model remains intact and users need to explicitly agree to access that would otherwise be prohibited. Michaela On 11/19/2014 12:01 AM, Jeffrey Walton wrote: On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Seems relevant: Java’s Losing Security Legacy, http://threatpost.com/javas-losing-security-legacy and Don't Sign that Applet!, https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. Dormann advises don't sign so that the code can't escape its sandbox and it stays restricted (malware regularly signs to do so).
Re: What I am missing
So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script. Signing itself doesn't establish any trust, or security. Yup, that's also what I meant. Signing does not imply secure, but to the average non-technical user a signed app from a trusted party may convey both trust and security, so they wouldn't think twice about installing such a script even if it asked for some powerful permissions that can be exploited by another script. Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... That's not working for a variety of reasons. The first reason is that identifying what a piece of software does intelligently is one of those really hard problems. As in Strong-AI hard. Well, the user can setup the rules of what is considered a malicious action and that there would be ready made configurations (best practices codified in config) that would be the default in the browser. And then they can exempt certain scripts. I realize this is an open ended problem and no solution is going to address it 100% ... It's the nature of open systems to be open to attacks but it's how the system deals with the attack that differentiates it. It's a wide open area of research I think, or should be. But do we want a security model that's not extensible and not flexible? The answer is most likely NO. On Tue, Nov 18, 2014 at 11:03 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com wrote: So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script. Signing itself doesn't establish any trust, or security. Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... That's not working for a variety of reasons. The first reason is that identifying what a piece of software does intelligently is one of those really hard problems. As in Strong-AI hard. Failing that, you can monitor what APIs a piece of software makes use of, and restrict access to those. However, that's already satisfied without signing by sandboxing. Furthermore, it doesn't entirely solve the problem as any android user will know. You get a ginormeous list of premissions a given piece of software would like to use and the user just clicks yes. Alternatively, you get malware that's not trustworthy, that nobody managed to properly review, because the non trusty part was burried/hidden by the author somewhere deep down, to activate only long after trust extension by fiat has happened. But even if you'd assume that this somehow would be an acceptable model, what do you define as malicious? Reformatting your machine would be malicious, but so would be posting on your facebook wall. What constitutes a malicious pattern is actually more of a social than a technical problem.
Re: What I am missing
How would an unsigned script be able to exploit functionality from a signed script if it's an either/or case - you have either all scripts signed or no extended features? and: Think about this: a website can be totally safe today and deliver exploits tomorrow without the user even noticing. It happened before and it will happen again. Signed content would prevent this by warning the user about missing or wrong signatures - even if signed script would not add a single extended function. I understand that signing code does not lead to the solution of all evils. But it would add another layer that needs to be broken if somebody gains access to a website and starts to modify code. Michaela On 11/19/2014 11:14 AM, Marc Fawzi wrote: So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script. Signing itself doesn't establish any trust, or security. Yup, that's also what I meant. Signing does not imply secure, but to the average non-technical user a signed app from a trusted party may convey both trust and security, so they wouldn't think twice about installing such a script even if it asked for some powerful permissions that can be exploited by another script. Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... That's not working for a variety of reasons. The first reason is that identifying what a piece of software does intelligently is one of those really hard problems. As in Strong-AI hard. Well, the user can setup the rules of what is considered a malicious action and that there would be ready made configurations (best practices codified in config) that would be the default in the browser. And then they can exempt certain scripts. I realize this is an open ended problem and no solution is going to address it 100% ... It's the nature of open systems to be open to attacks but it's how the system deals with the attack that differentiates it. It's a wide open area of research I think, or should be. But do we want a security model that's not extensible and not flexible? The answer is most likely NO. On Tue, Nov 18, 2014 at 11:03 PM, Florian Bösch pya...@gmail.com mailto:pya...@gmail.com wrote: On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com mailto:marc.fa...@gmail.com wrote: So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script. Signing itself doesn't establish any trust, or security. Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... That's not working for a variety of reasons. The first reason is that identifying what a piece of software does intelligently is one of those really hard problems. As in Strong-AI hard. Failing that, you can monitor what APIs a piece of software makes use of, and restrict access to those. However, that's already satisfied without signing by sandboxing. Furthermore, it doesn't entirely solve the problem as any android user will know. You get a ginormeous list of premissions a given piece of software would like to use and the user just clicks yes. Alternatively, you get malware that's not trustworthy, that nobody managed to properly review, because the non trusty part was burried/hidden by the author somewhere deep down, to activate only long after trust extension by fiat has happened. But even if you'd assume that this somehow would be an acceptable model, what do you define as malicious? Reformatting your machine would be malicious, but so would be posting on your facebook wall. What constitutes a malicious pattern is actually more of a social than a technical problem.
Re: What I am missing
Yes - it establishes provenance and protects against unauthorized manipulation. CSP is only as good as the content it protects. If the content has been manipulated server side - e.g. by unauthorized access - CSP is worthless. Michaela On 11/19/2014 10:03 AM, ☻Mike Samuel wrote: Browser signature checking gives you nothing that CSP doesn't as far as the security of pages composed from a mixture of content from different providers. As Florian points out, signing only establishes provenance, not any interesting security properties. I can always write a page that runs an interpreter on data loaded from a third-party source even if that data is not loaded as script, so a signed application is always open to confused deputy problems. Signing is a red herring which distracts from the real problem : the envelope model in which secrets are scoped to the whole content of the envelope, makes it hard to decompose a document into multiple trust domains that reflect the fact that the document is really composed of content with multiple different provenances. By the envelope model, I mean the assumption that the user-agent receives a document and a wrapper, and makes trust decisions for the whole of the document based on the content of the wrapper. The envelope does all of 1. establishing a trust domain, the origin 2. bundles secrets, usually in cookies and headers 3. bundles content, possibly from multiple sources. Ideally our protocols would be written in such a way that secrets can be scoped to content with a way to allow nesting without inheritance. This can be kludged on top of iframes, but only at the cost of a lot of engineering effort. On Wed, Nov 19, 2014 at 10:27 AM, Michaela Merz michaela.m...@hermetos.com wrote: I don't disagree. But what is wrong with the notion of introducing an _additional_ layer of certification? Signed script and/or html would most certainly make it way harder to de-face a website or sneak malicious code into an environment. I strongly believe that just for this reason alone, we should think about signed content - even without additional potentially unsafe functionality. Michaela On 11/19/2014 09:21 AM, Pradeep Kumar wrote: Michaela, As Josh said earlier, signing the code (somehow) will not enhance security. It will open doors for more threats. It's better and more open, transparent and in sync with the spirit of open web to give the control to end user and not making them to relax today on behalf of other signing authorities. On 19-Nov-2014 8:44 pm, Michaela Merz michaela.m...@hermetos.com wrote: You are correct. But all those services are (thankfully) sand boxed or read only. In order to make a browser into something even more useful, you have to relax these security rules a bit. And IMHO that *should* require signed code - in addition to the users consent. Michaela On 11/19/2014 09:09 AM, Pradeep Kumar wrote: Even today, browsers ask for permission for geolocation, local storage, camera etc... How it is different from current scenario? On 19-Nov-2014 8:35 pm, Michaela Merz michaela.m...@hermetos.com wrote: That is relevant and also not so. Because Java applets silently grant access to a out of sandbox functionality if signed. This is not what I am proposing. I am suggesting a model in which the sandbox model remains intact and users need to explicitly agree to access that would otherwise be prohibited. Michaela On 11/19/2014 12:01 AM, Jeffrey Walton wrote: On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Seems relevant: Java’s Losing Security Legacy, http://threatpost.com/javas-losing-security-legacy and Don't Sign that Applet!, https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. Dormann advises don't sign so that the code can't escape its sandbox and it stays restricted (malware regularly signs to do so).
Re: What I am missing
Allowing this script to run may open you to all kinds of malicious attacks by 3rd parties not associated with the party whom you're trusting. If I give App XYZ super power to do anything, and XYZ gets compromised/hacked then I'll be open to all sorts of attacks. It's not an issue of party A trusting party B. It's an issue of trusting that party B has no security holes in their app whatsoever, and that is one of the hardest things to guarantee. On Tue, Nov 18, 2014 at 8:00 PM, Michaela Merz michaela.m...@hermetos.com wrote: Yes Boris - I know. As long as it doesn't have advantages for the user or the developer - why bother with it? If signed code would allow special features - like true fullscreen or direct file access - it would make sense. Signed code would make script much more resistant to manipulation and therefore would help in environments where trust and/or security is important. We use script for much, much more than we did just a year or so ago. Michaela On 11/19/2014 04:40 AM, Boris Zbarsky wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html . In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. -Boris
Re: What I am missing
On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz michaela.m...@hermetos.com wrote: First: We need signed script code. We are doing a lot of stuff with script - we could safely do even more, if we would be able to safely deliver script that has some kind of a trust model. TLS exists. I am thinking about signed JAR files - just like we did with java applets not too long ago. Maybe as an extension to the CSP enviroment .. and a nice frame around the browser telling the user that the site is providing trusted / signed code. Which is different than TLS how? Signed code could allow more openness, like true full screen, Fullscreen is possible today, https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode or simpler ajax downloads. Simpler how? Second: It would be great to finally be able to accept incoming connections. WebRTC allows the browser to accept incoming connections. The WebRTC data channel covers both TCP and UDP connectivity. There's access to cameras and microphones - why not allow us the ability to code servers in the browser? You can. There's even P2P overlay networks being done with WebRTC. Although they're mostly hampered by the existing support for WebRTC data channels, which isn't great yet.
Re: What I am missing
Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Michaela On 11/19/2014 06:14 AM, Marc Fawzi wrote: Allowing this script to run may open you to all kinds of malicious attacks by 3rd parties not associated with the party whom you're trusting. If I give App XYZ super power to do anything, and XYZ gets compromised/hacked then I'll be open to all sorts of attacks. It's not an issue of party A trusting party B. It's an issue of trusting that party B has no security holes in their app whatsoever, and that is one of the hardest things to guarantee. On Tue, Nov 18, 2014 at 8:00 PM, Michaela Merz michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote: Yes Boris - I know. As long as it doesn't have advantages for the user or the developer - why bother with it? If signed code would allow special features - like true fullscreen or direct file access - it would make sense. Signed code would make script much more resistant to manipulation and therefore would help in environments where trust and/or security is important. We use script for much, much more than we did just a year or so ago. Michaela On 11/19/2014 04:40 AM, Boris Zbarsky wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html. In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. -Boris
Re: What I am missing
On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz michaela.m...@hermetos.com wrote: If signed code would allow special features - like true fullscreen https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode or direct file access http://www.html5rocks.com/en/tutorials/file/filesystem/
Re: What I am missing
TLS doesn't protect you against code that has been altered server side - without the signers consent. It would alert the user, if unsigned updates would be made available. Ajax downloads still require a download link (with the bloburl) to be displayed requiring an additional click. User clicks download .. ajax downloads the data, creates blob url as src which the user has to click to 'copy' the blob onto the userspace drive. Would be better to skip the final part. In regard to accept: I wasn't aware of the fact that I can accept a socket on port 80 to serve a HTTP session. You're saying I could with what's available today? Michaela On 11/19/2014 06:34 AM, Florian Bösch wrote: On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz michaela.m...@hermetos.com mailto:michaela.m...@hermetos.com wrote: First: We need signed script code. We are doing a lot of stuff with script - we could safely do even more, if we would be able to safely deliver script that has some kind of a trust model. TLS exists. I am thinking about signed JAR files - just like we did with java applets not too long ago. Maybe as an extension to the CSP enviroment .. and a nice frame around the browser telling the user that the site is providing trusted / signed code. Which is different than TLS how? Signed code could allow more openness, like true full screen, Fullscreen is possible today, https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode or simpler ajax downloads. Simpler how? Second: It would be great to finally be able to accept incoming connections. WebRTC allows the browser to accept incoming connections. The WebRTC data channel covers both TCP and UDP connectivity. There's access to cameras and microphones - why not allow us the ability to code servers in the browser? You can. There's even P2P overlay networks being done with WebRTC. Although they're mostly hampered by the existing support for WebRTC data channels, which isn't great yet.
Re: What I am missing
On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Seems relevant: Java’s Losing Security Legacy, http://threatpost.com/javas-losing-security-legacy and Don't Sign that Applet!, https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. Dormann advises don't sign so that the code can't escape its sandbox and it stays restricted (malware regularly signs to do so).
Re: What I am missing
Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner if I trust you and allow your signed script the permissions it asks for and you can't guarantee that it would be used by some malicious 3rd party site to hack me (i.e. the security holes in your script get turned against me) then there is just too much risk in allowing the permissions the concern is that the average user will not readily grasp the risk involved in granting certain powerful permissions to some insecure script from a trusted source On Tue, Nov 18, 2014 at 9:35 PM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. Michaela On 11/19/2014 06:14 AM, Marc Fawzi wrote: Allowing this script to run may open you to all kinds of malicious attacks by 3rd parties not associated with the party whom you're trusting. If I give App XYZ super power to do anything, and XYZ gets compromised/hacked then I'll be open to all sorts of attacks. It's not an issue of party A trusting party B. It's an issue of trusting that party B has no security holes in their app whatsoever, and that is one of the hardest things to guarantee. On Tue, Nov 18, 2014 at 8:00 PM, Michaela Merz michaela.m...@hermetos.com wrote: Yes Boris - I know. As long as it doesn't have advantages for the user or the developer - why bother with it? If signed code would allow special features - like true fullscreen or direct file access - it would make sense. Signed code would make script much more resistant to manipulation and therefore would help in environments where trust and/or security is important. We use script for much, much more than we did just a year or so ago. Michaela On 11/19/2014 04:40 AM, Boris Zbarsky wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html . In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. -Boris
Re: What I am missing
On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only guarantees that the code is actually from the the certificate owner .. and has not been altered without the signers consent. On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz michaela.m...@hermetos.com wrote: it would make sense. Signed code would make script much more resistant to manipulation and therefore would help in environments where trust and/or security is important. We use script for much, much more than we did just a year or so ago. On Wed, Nov 19, 2014 at 6:41 AM, Michaela Merz michaela.m...@hermetos.com wrote: TLS doesn't protect you against code that has been altered server side - without the signers consent. It would alert the user, if unsigned updates would be made available. Signing allows you to verify that an entity did produce a run of bytes, and not another entity. Entity here meaning the holder of the private key who put his signature onto that run of bytes. How do you know this entity did that? Said entity also broadcast their public key, so that the recipient can compare. TLS solves this problem somewhat by securing the delivery channel. It doesn't sign content, but via TLS it is (at least proverbially) impossible for somebody to deliver content over a channel you control. Ajax downloads still require a download link (with the bloburl) to be displayed requiring an additional click. User clicks download .. ajax downloads the data, creates blob url as src which the user has to click to 'copy' the blob onto the userspace drive. Would be better to skip the final part. Signing, technically would have an advantage where you wish to deliver content over a channel that you cannot control. Such as over WebRTC, from files, and so forth. In regard to accept: I wasn't aware of the fact that I can accept a socket on port 80 to serve a HTTP session. You're saying I could with what's available today? You cannot. You can however let the browser accept an incoming connection under the condition that they're browsing the same origin. The port doesn't matter as much, as WebRTC largely relegates it to an implementation detail of the channel negotiator so that two of the same origins can communicate. Suppose you get a piece of signed content, over whatever way it was delivered. Suppose also that this content you got has the ability to read all your private data, or reformat your machine. So it's basically about trust. You need to establish a secure channel of communication to obtain a public key that matches a signature, in such a way that an attackers attempt to self-sign malicious content is foiled. And you need to have a way to discover (after having established that the entity is the one who was intended and that the signature is correct), that you indeed trust that entity. These are two very old problems in cryptography, and they cannot be solved by cryptography. There are various approaches to this problem in use today: - TLS and its web of trust: The basic idea being that there is a hierarchy of signatories. It works like this. An entity provides a certificate for the connection, signing it with their private key. Since you cannot establish a connection without a public key that matches the private key, verifying the certificate is easy. This entity in turn, refers to another entity which provided the signature for that private key. They refer to another one, and so forth, until you arrive at the root. You implicitly trust root. This works, but it has some flaws. At the edge of the web, people are not allowed to self-sign, so they obtain their (pricey) key from the next tier up. But the next tier up can't go and bother the next tier up everytime they need to provide a new set of keys to the edge. So they get blanket permission to self-sign, implying that it's possible for the next tier up to establish and maintain a trust relationship to them. As is easily demonstratable, this can, and often does, go wrong, where some CA gets compromised. This is always bad news to whomever obtained a certificate from them, because now a malicious party can pass themselves off as them. - App-stores and trust royalty: This is really easy to describe, the app store you obtain something from signs the content, and you trust the app-store, and therefore you trust the content. This can, and often does go wrong, as android/iOS malware amply demonstrates. TSL cannot work perfectly, because it is built on implied trust along the chain, and this can get compromised. App-stores cannot work perfectly because the ability to review content is quickly exceeded by the flood of content. Even if app-stores where provided with the full source,
Re: What I am missing
There are some models that are a bit better than trust by royalty (app-stores) and trust by hirarchy (TLS). One of them is trust flowing along flow limited edges in a graph (as in Advogato). This model however isn't free from fault, as when a highly trusted entity gets compromised, there's no quick or easy way to revoke that trust for that entity. Also, a trust graph such as this doesn't solve the problem of stake. We trust say, the twitter API, because we know that twitter has staked a lot into it. If they violate that trust, they suffer proportionally more. A graph doesn't solve that problem, because it cannot offer a proof of stake. Interestingly, there are way to provide a proof of stake (see various cryptocurrencies that attempt to do that). Of course proof of stake cryptocurrencies have their own problems, but that doesn't entirely invalidate the idea. If you can prove you have a stake of a given size, then you can enhance a flow limited trust graph insofar as to make it less likely an entity gets compromised. The difficulty with that approach of course is, it would make aquiring high levels of trust prohibitively expensive (as in getting the priviledge to access the filesystem could run you into millions of $ of stake shares).
Re: What I am missing
So there is no way for an unsigned script to exploit security holes in a signed script? Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... On Tue, Nov 18, 2014 at 10:34 PM, Florian Bösch pya...@gmail.com wrote: There are some models that are a bit better than trust by royalty (app-stores) and trust by hirarchy (TLS). One of them is trust flowing along flow limited edges in a graph (as in Advogato). This model however isn't free from fault, as when a highly trusted entity gets compromised, there's no quick or easy way to revoke that trust for that entity. Also, a trust graph such as this doesn't solve the problem of stake. We trust say, the twitter API, because we know that twitter has staked a lot into it. If they violate that trust, they suffer proportionally more. A graph doesn't solve that problem, because it cannot offer a proof of stake. Interestingly, there are way to provide a proof of stake (see various cryptocurrencies that attempt to do that). Of course proof of stake cryptocurrencies have their own problems, but that doesn't entirely invalidate the idea. If you can prove you have a stake of a given size, then you can enhance a flow limited trust graph insofar as to make it less likely an entity gets compromised. The difficulty with that approach of course is, it would make aquiring high levels of trust prohibitively expensive (as in getting the priviledge to access the filesystem could run you into millions of $ of stake shares).
Re: What I am missing
On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com wrote: So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script. Signing itself doesn't establish any trust, or security. Funny you mention crypto currencies as an idea to get inspiration from...Trust but verify is detached from that... a browser can monitor what the signed scripts are doing and if it detects a potentially malicious pattern it can halt the execution of the script and let the user decide if they want to continue... That's not working for a variety of reasons. The first reason is that identifying what a piece of software does intelligently is one of those really hard problems. As in Strong-AI hard. Failing that, you can monitor what APIs a piece of software makes use of, and restrict access to those. However, that's already satisfied without signing by sandboxing. Furthermore, it doesn't entirely solve the problem as any android user will know. You get a ginormeous list of premissions a given piece of software would like to use and the user just clicks yes. Alternatively, you get malware that's not trustworthy, that nobody managed to properly review, because the non trusty part was burried/hidden by the author somewhere deep down, to activate only long after trust extension by fiat has happened. But even if you'd assume that this somehow would be an acceptable model, what do you define as malicious? Reformatting your machine would be malicious, but so would be posting on your facebook wall. What constitutes a malicious pattern is actually more of a social than a technical problem.
Re: What I am missing
On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/18/14, 10:26 PM, Michaela Merz wrote: First: We need signed script code. For what it's worth, Gecko supported this for a while. See http://www-archive.mozilla.org/projects/security/components/signed-scripts.html. In practice, people didn't really use it, and it made the security model a _lot_ more complicated and hard to reason about, so the feature was dropped. It would be good to understand how proposals along these lines differ from what's already been tried and failed. The way we did script signing back then was nutty in several ways. The signing we do in FirefoxOS is *much* simpler. Simple enough that no one has complained about the complexity that it has added to Gecko. Sadly enhanced security models that use signing by a trusted party inherently looses a lot of the advantages of the web. It means that you can't publish a new version of you website by simply uploading files to your webserver whenever you want. And it means that you can't generate the script and markup that make up your website dynamically on your webserver. So I'm by no means arguing that FirefoxOS has the problem of signing solved. Unfortunately no one has been able to solve the problem of how to grant web content access to capabilities like raw TCP or UDP sockets in order to access legacy hardware and protocols, or how to get read/write acccess to your photo library in order to build a photo manager, without relying on signing. Which has meant that the web so far is unable to compete with native in those areas. / Jonas
Re: What I am missing
On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch pya...@gmail.com wrote: or direct file access http://www.html5rocks.com/en/tutorials/file/filesystem/ This is no more direct file access than IndexedDB is. IndexedDB also allow you to store File objects, but also doesn't allow you to access things like your photo or music library. / Jonas
