Running trusted code in the untrusted web - A writeup
For those who frown at the idea of calling native (trusted) applications from the untrusted web [1], here is a writeup of how you could run trusted web-code inside of a untrusted web-application. Regarding the use-cases, there are many ranging from phone-dialers on support pages to payments [2]. Since you probably do not want to rewrite browsers from scratch, the most logical is building on running trusted code in IFRAMEs so that the existing protection scheme can be reused. The difference with existing IFRAMEs is that the code must be trusted by the platform which also means that it must be fetched from the platform: This code should appear to the browser as coming from a virtual domain. The only communication possible is through postMessage(). If the referenced application isn't available in the local cache, the browser should presumably consult the device-specific "AppStore". A side-effect of this "specification" is that trusted web-applications may be device-specific which actually is a plus since it reduces the need to standardize access to the OS and HW layer. That is, there could be a new class of standardized trusted web-applications where only the invoke/postMessage part is standardized! Cheers, Anders Rundgren 1] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html 2] Although not entirely compliant with the above, the following demo https://mobilepki.org/WebCryptoPlusPlus does the same thing from a user's perfective.
Re: The futile war between Native and Web
On 2015-02-16 18:07, Anne van Kesteren wrote: On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren wrote: Anyway, I think we will soon see that Apple simply "calls" their Apple Pay "App" from the web because it preserves all the goodies "as is". Why is simple and practical wrong? Is anyone saying that's wrong? What's wrong is the comparison between "native" and "web". Well, I have provided a concrete solution for combining native (running trusted code) and web (running untrusted code) which I originally got from Google and is already in practical use. If somebody has a better solution there's huge community out there who is waiting. Anders Apple Pay could not have been created through the App Store model either. It's a feature of iOS coupled with the hardware found in the latest iPhone. If we get browsers that operate at the OS level they could deliver similar features. If they don't operate at the OS level they could integrate with what the OS provides. Either way this is something that requires new APIs and UX, whether "native" or "web".
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 5:53 PM, Anders Rundgren wrote: > Anyway, I think we will soon see that Apple simply "calls" their Apple Pay > "App" from the web because it preserves all the goodies "as is". > Why is simple and practical wrong? Is anyone saying that's wrong? What's wrong is the comparison between "native" and "web". Apple Pay could not have been created through the App Store model either. It's a feature of iOS coupled with the hardware found in the latest iPhone. If we get browsers that operate at the OS level they could deliver similar features. If they don't operate at the OS level they could integrate with what the OS provides. Either way this is something that requires new APIs and UX, whether "native" or "web". -- https://annevankesteren.nl/
Re: The futile war between Native and Web
On 2015-02-16 17:27, Michaela Merz wrote: Well - there is no "direct" pathway between the browser and the chip card terminal. And .. of course can the user manipulate all of Javascript client-side, eg. patch variables to his liking. But that is true (though harder) for any code that runs client side. The card terminal could provide a rest api that would allow a browser to post the amount to be paid into the terminal. That would be a very safe solution - not only in regard to web, but in regard to any communications with the card terminal as there would be now vulnerable code on the client. On the web there is no card terminal so it has to be emulated by client code. Who is supposed to sign this code? How is it invoked by a web merchant? How it is distributed? So my discussion has nothing to do about vulnerability of JS. Anyway, I think we will soon see that Apple simply "calls" their Apple Pay "App" from the web because it preserves all the goodies "as is". Why is simple and practical wrong? Anders mm. On 02/16/2015 10:19 AM, Anders Rundgren wrote: > On 2015-02-16 16:54, Michaela Merz wrote: >> This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). > > On paper it is doable, in reality it is not. > > You would anyway end-up with proprietary "AppStores" with granted "Apps" and then I don't really see the point insisting on using web-technology anymore. > General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running. > > Anders > >> >> I am aware of the old notion, that JavaScript crypto is not "safe". But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. >> >> Michaela >> >> On 02/16/2015 03:40 AM, Anders Rundgren wrote: >> > On 2015-02-16 09:34, Anne van Kesteren wrote: >> >> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: >> >>> For the first point, Pinning with Overrides >> >>> (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect >> >>> example of the wrong security model. The organizations I work with did >> >>> not drink the Web 2.0 koolaide, its its not acceptable to them that an >> >>> adversary can so easily break the secure channel. >> >> >> >> What would you suggest instead? >> >> >> >> >> >>> For the second point, and as a security architect, I regularly reject >> >>> browser-based apps that operate on medium and high value data because >> >>> we can't place the security controls needed to handle the data. The >> >>> browser based apps are fine for low value data. >> >>> >> >>> An example of the lack of security controls is device provisioning and >> >>> client authentication. We don't have protected or isolated storage, >> >>> browsers can't safely persist provisioning shared secrets, secret >> >>> material is extractable (even if marked non-extractable), browsers >> >>> can't handle client certificates, browsers are more than happy to >> >>> cough up a secret to any server with a certificate or public key (even >> >>> the wrong ones), ... >> >> >> >> So you would like physical storage on disk to be segmented by eTLD+1 >> >> or some such? >> >> >> >> As for the certificate issues, did you file bugs? >> >> >> >> >> >> I think there definitely is interest in making the web suitable for >> >> this over time. It would help if the requirements were documented >> >> somewhere. >> > >> > There are no universal and agreed-upon requirements for dealing with >> > client-certificates which is why this has been carried out in the past >> > through proprietary plugins. These have now been outlawed (for good >> > reasons), but no replacement has been considered. >> > >> > There were some efforts recently >> > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ >> > which though were rejected by Mozilla, Google and Facebook. >> > >> > And there we are...which I suggest a "short-cut": >> > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html >> > which initially was pointed out by Ryan Sleevy: >> > https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html >> > >> > Anders >> > >> >> > >
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 11:19 AM, Anders Rundgren wrote: > ... > > You would anyway end-up with proprietary "AppStores" with granted "Apps" and > then I don't really see the point insisting on using web-technology anymore. > General code-signing like used in Windows application doesn't help, it is > just one OK button more to click before running. The interesting thing about App Stores and Code Signing is it provides vendor lock-in and maintains revenue streams. So while it has [sometimes] questionable value, its something that we are going to see a lot more of as vendors unofficially use it as a tool to further their internal agendas. Look at how many vendors are supporting Installable Web Apps. Installable Web Apps effectively turns any web server into an App Store. The answer is: Mozilla and Chrome. Jeff
Re: The futile war between Native and Web
Well - there is no "direct" pathway between the browser and the chip card terminal. And .. of course can the user manipulate all of Javascript client-side, eg. patch variables to his liking. But that is true (though harder) for any code that runs client side. The card terminal could provide a rest api that would allow a browser to post the amount to be paid into the terminal. That would be a very safe solution - not only in regard to web, but in regard to any communications with the card terminal as there would be now vulnerable code on the client. mm. On 02/16/2015 10:19 AM, Anders Rundgren wrote: > On 2015-02-16 16:54, Michaela Merz wrote: >> This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). > > On paper it is doable, in reality it is not. > > You would anyway end-up with proprietary "AppStores" with granted "Apps" and then I don't really see the point insisting on using web-technology anymore. > General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running. > > Anders > >> >> I am aware of the old notion, that JavaScript crypto is not "safe". But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. >> >> Michaela >> >> On 02/16/2015 03:40 AM, Anders Rundgren wrote: >> > On 2015-02-16 09:34, Anne van Kesteren wrote: >> >> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: >> >>> For the first point, Pinning with Overrides >> >>> (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect >> >>> example of the wrong security model. The organizations I work with did >> >>> not drink the Web 2.0 koolaide, its its not acceptable to them that an >> >>> adversary can so easily break the secure channel. >> >> >> >> What would you suggest instead? >> >> >> >> >> >>> For the second point, and as a security architect, I regularly reject >> >>> browser-based apps that operate on medium and high value data because >> >>> we can't place the security controls needed to handle the data. The >> >>> browser based apps are fine for low value data. >> >>> >> >>> An example of the lack of security controls is device provisioning and >> >>> client authentication. We don't have protected or isolated storage, >> >>> browsers can't safely persist provisioning shared secrets, secret >> >>> material is extractable (even if marked non-extractable), browsers >> >>> can't handle client certificates, browsers are more than happy to >> >>> cough up a secret to any server with a certificate or public key (even >> >>> the wrong ones), ... >> >> >> >> So you would like physical storage on disk to be segmented by eTLD+1 >> >> or some such? >> >> >> >> As for the certificate issues, did you file bugs? >> >> >> >> >> >> I think there definitely is interest in making the web suitable for >> >> this over time. It would help if the requirements were documented >> >> somewhere. >> > >> > There are no universal and agreed-upon requirements for dealing with >> > client-certificates which is why this has been carried out in the past >> > through proprietary plugins. These have now been outlawed (for good >> > reasons), but no replacement has been considered. >> > >> > There were some efforts recently >> > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ >> > which though were rejected by Mozilla, Google and Facebook. >> > >> > And there we are...which I suggest a "short-cut": >> > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html >> > which initially was pointed out by Ryan Sleevy: >> > https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html >> > >> > Anders >> > >> >> > >
Re: The futile war between Native and Web
On 2015-02-16 16:54, Michaela Merz wrote: This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). On paper it is doable, in reality it is not. You would anyway end-up with proprietary "AppStores" with granted "Apps" and then I don't really see the point insisting on using web-technology anymore. General code-signing like used in Windows application doesn't help, it is just one OK button more to click before running. Anders I am aware of the old notion, that JavaScript crypto is not "safe". But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. Michaela On 02/16/2015 03:40 AM, Anders Rundgren wrote: > On 2015-02-16 09:34, Anne van Kesteren wrote: >> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: >>> For the first point, Pinning with Overrides >>> (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect >>> example of the wrong security model. The organizations I work with did >>> not drink the Web 2.0 koolaide, its its not acceptable to them that an >>> adversary can so easily break the secure channel. >> >> What would you suggest instead? >> >> >>> For the second point, and as a security architect, I regularly reject >>> browser-based apps that operate on medium and high value data because >>> we can't place the security controls needed to handle the data. The >>> browser based apps are fine for low value data. >>> >>> An example of the lack of security controls is device provisioning and >>> client authentication. We don't have protected or isolated storage, >>> browsers can't safely persist provisioning shared secrets, secret >>> material is extractable (even if marked non-extractable), browsers >>> can't handle client certificates, browsers are more than happy to >>> cough up a secret to any server with a certificate or public key (even >>> the wrong ones), ... >> >> So you would like physical storage on disk to be segmented by eTLD+1 >> or some such? >> >> As for the certificate issues, did you file bugs? >> >> >> I think there definitely is interest in making the web suitable for >> this over time. It would help if the requirements were documented >> somewhere. > > There are no universal and agreed-upon requirements for dealing with > client-certificates which is why this has been carried out in the past > through proprietary plugins. These have now been outlawed (for good > reasons), but no replacement has been considered. > > There were some efforts recently > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ > which though were rejected by Mozilla, Google and Facebook. > > And there we are...which I suggest a "short-cut": > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html > which initially was pointed out by Ryan Sleevy: > https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html > > Anders >
Re: The futile war between Native and Web
This discussion is (in part) superfluous. Because a lot of people and organizations are using the web even for the most secure applications. Heck - they even send confidential data via plain old e-mail - they would even use AOL if that would still be possible - in other words: Most simply don't care. The web is THE universal applicable platform for .. well .. everything. So - it's the job of the browser vendors in cooperation with the web-developers to provide an environment that is up to the task. And I strongly believe that a safe and secure JavaScript environment is achievable as long as the browsers do their part (strict isolation between tabs would be such a thing). I am aware of the old notion, that JavaScript crypto is not "safe". But I say it *can*' be. CSP is a huge leap forward to make the browser a safe place for the handling of confidential data. Michaela On 02/16/2015 03:40 AM, Anders Rundgren wrote: > On 2015-02-16 09:34, Anne van Kesteren wrote: >> On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: >>> For the first point, Pinning with Overrides >>> (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect >>> example of the wrong security model. The organizations I work with did >>> not drink the Web 2.0 koolaide, its its not acceptable to them that an >>> adversary can so easily break the secure channel. >> >> What would you suggest instead? >> >> >>> For the second point, and as a security architect, I regularly reject >>> browser-based apps that operate on medium and high value data because >>> we can't place the security controls needed to handle the data. The >>> browser based apps are fine for low value data. >>> >>> An example of the lack of security controls is device provisioning and >>> client authentication. We don't have protected or isolated storage, >>> browsers can't safely persist provisioning shared secrets, secret >>> material is extractable (even if marked non-extractable), browsers >>> can't handle client certificates, browsers are more than happy to >>> cough up a secret to any server with a certificate or public key (even >>> the wrong ones), ... >> >> So you would like physical storage on disk to be segmented by eTLD+1 >> or some such? >> >> As for the certificate issues, did you file bugs? >> >> >> I think there definitely is interest in making the web suitable for >> this over time. It would help if the requirements were documented >> somewhere. > > There are no universal and agreed-upon requirements for dealing with > client-certificates which is why this has been carried out in the past > through proprietary plugins. These have now been outlawed (for good > reasons), but no replacement has been considered. > > There were some efforts recently > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ > which though were rejected by Mozilla, Google and Facebook. > > And there we are...which I suggest a "short-cut": > https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html > which initially was pointed out by Ryan Sleevy: > https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html > > Anders >
Re: The futile war between Native and Web
On 2015-02-16 09:34, Anne van Kesteren wrote: On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: For the first point, Pinning with Overrides (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect example of the wrong security model. The organizations I work with did not drink the Web 2.0 koolaide, its its not acceptable to them that an adversary can so easily break the secure channel. What would you suggest instead? For the second point, and as a security architect, I regularly reject browser-based apps that operate on medium and high value data because we can't place the security controls needed to handle the data. The browser based apps are fine for low value data. An example of the lack of security controls is device provisioning and client authentication. We don't have protected or isolated storage, browsers can't safely persist provisioning shared secrets, secret material is extractable (even if marked non-extractable), browsers can't handle client certificates, browsers are more than happy to cough up a secret to any server with a certificate or public key (even the wrong ones), ... So you would like physical storage on disk to be segmented by eTLD+1 or some such? As for the certificate issues, did you file bugs? I think there definitely is interest in making the web suitable for this over time. It would help if the requirements were documented somewhere. There are no universal and agreed-upon requirements for dealing with client-certificates which is why this has been carried out in the past through proprietary plugins. These have now been outlawed (for good reasons), but no replacement has been considered. There were some efforts recently http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ which though were rejected by Mozilla, Google and Facebook. And there we are...which I suggest a "short-cut": https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html which initially was pointed out by Ryan Sleevy: https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/.html Anders
Re: The futile war between Native and Web
On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: > For the first point, Pinning with Overrides > (tools.ietf.org/html/draft-ietf-websec-key-pinning) is a perfect > example of the wrong security model. The organizations I work with did > not drink the Web 2.0 koolaide, its its not acceptable to them that an > adversary can so easily break the secure channel. What would you suggest instead? > For the second point, and as a security architect, I regularly reject > browser-based apps that operate on medium and high value data because > we can't place the security controls needed to handle the data. The > browser based apps are fine for low value data. > > An example of the lack of security controls is device provisioning and > client authentication. We don't have protected or isolated storage, > browsers can't safely persist provisioning shared secrets, secret > material is extractable (even if marked non-extractable), browsers > can't handle client certificates, browsers are more than happy to > cough up a secret to any server with a certificate or public key (even > the wrong ones), ... So you would like physical storage on disk to be segmented by eTLD+1 or some such? As for the certificate issues, did you file bugs? I think there definitely is interest in making the web suitable for this over time. It would help if the requirements were documented somewhere. -- https://annevankesteren.nl/
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 3:17 AM, Florian Bösch wrote: > On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton wrote: >> >> I'd hardly consider an account holder's data as high value. Medium at >> best and likely low value. But that's just me. > > Of course if the data is compromised it means that an attacker can also > remote-control your e-banking interface, and issue payments and so forth. > I'm sure that's not "high value" either? No, that's definitely not high value from my experience with three US financial firms. In US financial, those losses are simply passed on to share holders. Risk is democratized, reward is privatized. Perhaps you should talk to other security architects with experience in financial and see what they have to say. Jeff
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton wrote: > I'd hardly consider an account holder's data as high value. Medium at > best and likely low value. But that's just me. > Of course if the data is compromised it means that an attacker can also remote-control your e-banking interface, and issue payments and so forth. I'm sure that's not "high value" either?
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 2:15 AM, Florian Bösch wrote: > On Mon, Feb 16, 2015 at 8:09 AM, Anders Rundgren > wrote: >> >> Unfortunately this is wrong and is why I started this thread. Mobile >> banking applications in Europe are usually featured as "Apps". >> This has multiple reasons; one is that there's no way to deal with >> client-side PKI and secure key storage in the mobile web. > > > Well Postfinance, Credit Suisse and UBS all have browser based e-banking > solutions. Some of them have "Apps" (usually on iOS/Android) in the > app-stores, but these are usually just web-widgets put in a container so > they can put it on the store. I'd hardly consider an account holder's data as high value. Medium at best and likely low value. But that's just me. Jeff
Re: The futile war between Native and Web
On Mon, Feb 16, 2015 at 1:48 AM, Florian Bösch wrote: > On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote: >> >> For the second point, and as a security architect, I regularly reject >> browser-based apps that operate on medium and high value data because >> we can't place the security controls needed to handle the data. The >> browser based apps are fine for low value data. > > I'm not sure what "high value data" is. But I'm fairly sure that just about > any e-banking solution in existence is browser based. So I'm guessing your > definition of "high value data" doesn't include banking access. You work for > the NSA? Oh snap, the high value data just walked out there on a USB stick. Each organization classifies its own data according to its own risk posture. High value data would include, for example, Executive Compensation, Pending Litigation, and Mergers & Acquisitions. Heck, even some movie studios classify movie trailers as high value until they are released in theaters. I don't work for the NSA, but I have done a lot of work in US Federal and the US DoD. I have not drank the Web 2.0 koolaide. We still need security controls commensurate with the data sensitivity level. Jeff
