6 ms·

Could some please please please explain what this "webapp crypto problem" thing is. I think of a browser as a client. Isn't the javascript done client-side. Why

Could some please please please explain what this "webapp crypto problem" thing is. I think of a browser as a client. Isn't the javascript done client-side. Why is everybody saying that the browser (javascript) is a broken platform for crypto. Have a even characterised what the issue is correctly? I don't even know. I figure that if this is explained to me then surely the solution should present itself at the same time :)

DrewHintz 13y ago
If your browser gets JavaScript crypto from webmail.example.com every time you visit webmail.example.com then there's nothing stopping webmail.example.com from serving malicious JavaScript crypto that steals your keys or unencrypted data. Even though the JavaScript runs locally, the code is supplied by webmail.example.com. There's a discussion of this and a few other issues here: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.
- igravious 13y ago
  Ahhh. I see. But of course, how dim of me. In that case, why do we trust e-commerce? Are we stupid to trust e-commerce? Am I right in saying though that if the javascript has been signed that the browser could trust it assuming the browser could trust webmail.example.com I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance ...
  - tptacek 13y ago
    E-commerce doesn't rely on Javascript cryptography. You generally don't trust code updates, which is one reason you do them infrequently; every time you update code there's an opportunity for someone who has corrupted the update process to take over your machine. A Javascript application might need to update itself several times per second across a single execution of itself.
    - igravious 13y ago
      Would there be a way of hooking important Javascript blobs into the OS update/store/packaging mechanism or am I being completely dense? Say I don't trust code updates which is why I choose to run Uuntu because I like its central package management system. Is it entirely infeasible to leverage that update mechanism to enable end-to-end crypto communication in the browser or are these entirely separate issues? Is it your contention that the browser is not the correct platform for end-to-end crypto communication? edit: it's ok - you needn't reply, I've read some of your other posts and I get that you'd tell me that there are DOM considerations as well.
      - tptacek 13y ago
        Are you noticing how hard it is to reason through the security model of Javascript crypto code? How many different interactions there are you'd need to account for? That's a big part of the problem, and it's a problem that simply doesn't exist in the same way for native code.
        igravious 13y ago
        Dang, fell asleep there mid-conversation :/ I am noticing that it is unexpectedly difficult to reason through the security model of Javascript crypto code. And you sure are patient, and I thank you for bringing about that realisation. It is beginning to dawn on me that it is amazing how _happily_ we allow any random site to go ahead and use are CPUs to do _God knows what_ as soon as we visit their site. That's rather trusting of us when you think about it. But we gotta. Because why? Because dynamic content supposedly; it was easier to have Turing-complete Javascript than figure out how to make HTML/CSS dynamic. Never mind that a generic VM approach should have been taken if that's what you're gonna do, and let random site-designer Jo(sephin)e choose the language they like hacking with rather than create yet another language that we're all going to bitch and moan about. And you can tell that the assembler for the Web / VM approach should have been taken because that's what Javascript is becoming. Exhibit A: ASM.js And at the time we should have figured out that in addition to sandboxing we also needed a security model that would cater for end-to-end secure (anonymous?) communication. Pity we couldn't see 20 years down the road. Now we're stuck with Javascript (which I actually like, don't get me wrong) and GMail (which I'm regretting that I use, nowadays) . sigh
  - riquito 13y ago
    > Why should I trust a security update from Apple, Microsoft, or Canonical for instance Because it's your operative system and you can't realistically read and compile each time the patches (if you have the sources). If your operative system is against you you've utterly lost, so your best bets are to both trust them and use 100000 eyes to find bogus patches (open source OS)
  - riquito 13y ago
    > why do we trust e-commerce? Are we stupid to trust e-commerce? well, many don't trust it, with good reason, and use temporary credit cards (sorry, can't remember the correct name for that but I hope it's clear enough)
  - betterunix 13y ago
    "I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance" The difference is that it is very hard to specifically target someone via an OS update. It is very easy to specifically target a web app user: http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ Now, if you were forced to log in or to otherwise uniquely identify yourself before you received OS updates, this would be different.
- elBob 13y ago
  I'd like to point to this http://blog.opal.io/crypto-in-the-browser.html http://blog.opal.io/crypto-in-the-browser.html
  - tptacek 13y ago
    And here's the thread taking that post apart: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6637915
- deleted 13y ago
  [deleted]
bradleyjg 13y ago
Let's say Bob wants to communicate with Alice, and he doesn't want Sergey to be able to read his message, but Sergey writes the software that they want to use to communicate. In a peer to peer setup, Bob and Alice only need to trust a discrete piece of software they download from Sergey at a given point in time. Maybe that software is open source so they can audit it and thereafter have confidence in it. But if Sergey is instead releasing his software as a javascript program to be run in a web browser than they need to trust Sergey each and every time they run the program, because they are downloading the program anew each and every time they want to use it. Even if Sergey is a stand up guy, this setup means that the government can force him to break his promise at any time, whereas if he had put out a discrete set of software versions, particularly if they were open source with a public source control, he could plausibly tell the government that what they were asking was impossible.
- igravious 13y ago
  So the question becomes one of modifying the browser Javascript delivery mechanism to allow a more secure & discrete versions channel that would require user intervention. Or could there be another possible way?
  - bradleyjg 13y ago
    There's already a mechanism in place for that in the form of javascript plugins/extensions/scripts which have to be explicitly installed. There's still problems because downloaded javascript can run in the same context and subvert the installed javascript. I believe tptacek has written a blog post elaborating on the problems with that. In a larger sense, I would push back against the web browser as a general purpose OS. We already have a few battle tested OSes who designers have put great thought and effort into these problems. If you insist on javascript, there's even node.js programs, albeit generally installed outside of the usual OS specific mechanisms. If you insist on HTML/css for layout and javascript for programming, I believe there are toolkits based on webkit, chromium and IE that let you create a standalone program embedding the respective browser engines. You can even do what mailpile is doing and embed a web sever in your client application and use your web browser as a client to the client acting as a server (though this last seems a little Rube Golderg-esque to me). But in any event downloaded and installed like a full fledged program rather than treating the exercise as though you were going to a special website.

DrewHintz 13y ago

If your browser gets JavaScript crypto from webmail.example.com every time you visit webmail.example.com then there's nothing stopping webmail.example.com from serving malicious JavaScript crypto that steals your keys or unencrypted data. Even though the JavaScript runs locally, the code is supplied by webmail.example.com. There's a discussion of this and a few other issues here: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.

igravious 13y ago
Ahhh. I see. But of course, how dim of me. In that case, why do we trust e-commerce? Are we stupid to trust e-commerce? Am I right in saying though that if the javascript has been signed that the browser could trust it assuming the browser could trust webmail.example.com I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance ...
- tptacek 13y ago
  E-commerce doesn't rely on Javascript cryptography. You generally don't trust code updates, which is one reason you do them infrequently; every time you update code there's an opportunity for someone who has corrupted the update process to take over your machine. A Javascript application might need to update itself several times per second across a single execution of itself.
  - igravious 13y ago
    Would there be a way of hooking important Javascript blobs into the OS update/store/packaging mechanism or am I being completely dense? Say I don't trust code updates which is why I choose to run Uuntu because I like its central package management system. Is it entirely infeasible to leverage that update mechanism to enable end-to-end crypto communication in the browser or are these entirely separate issues? Is it your contention that the browser is not the correct platform for end-to-end crypto communication? edit: it's ok - you needn't reply, I've read some of your other posts and I get that you'd tell me that there are DOM considerations as well.
    - tptacek 13y ago
      Are you noticing how hard it is to reason through the security model of Javascript crypto code? How many different interactions there are you'd need to account for? That's a big part of the problem, and it's a problem that simply doesn't exist in the same way for native code.
      - igravious 13y ago
        Dang, fell asleep there mid-conversation :/ I am noticing that it is unexpectedly difficult to reason through the security model of Javascript crypto code. And you sure are patient, and I thank you for bringing about that realisation. It is beginning to dawn on me that it is amazing how _happily_ we allow any random site to go ahead and use are CPUs to do _God knows what_ as soon as we visit their site. That's rather trusting of us when you think about it. But we gotta. Because why? Because dynamic content supposedly; it was easier to have Turing-complete Javascript than figure out how to make HTML/CSS dynamic. Never mind that a generic VM approach should have been taken if that's what you're gonna do, and let random site-designer Jo(sephin)e choose the language they like hacking with rather than create yet another language that we're all going to bitch and moan about. And you can tell that the assembler for the Web / VM approach should have been taken because that's what Javascript is becoming. Exhibit A: ASM.js And at the time we should have figured out that in addition to sandboxing we also needed a security model that would cater for end-to-end secure (anonymous?) communication. Pity we couldn't see 20 years down the road. Now we're stuck with Javascript (which I actually like, don't get me wrong) and GMail (which I'm regretting that I use, nowadays) . sigh
- riquito 13y ago
  > Why should I trust a security update from Apple, Microsoft, or Canonical for instance Because it's your operative system and you can't realistically read and compile each time the patches (if you have the sources). If your operative system is against you you've utterly lost, so your best bets are to both trust them and use 100000 eyes to find bogus patches (open source OS)
- riquito 13y ago
  > why do we trust e-commerce? Are we stupid to trust e-commerce? well, many don't trust it, with good reason, and use temporary credit cards (sorry, can't remember the correct name for that but I hope it's clear enough)
- betterunix 13y ago
  "I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance" The difference is that it is very hard to specifically target someone via an OS update. It is very easy to specifically target a web app user: http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ Now, if you were forced to log in or to otherwise uniquely identify yourself before you received OS updates, this would be different.
elBob 13y ago
I'd like to point to this http://blog.opal.io/crypto-in-the-browser.html http://blog.opal.io/crypto-in-the-browser.html
- tptacek 13y ago
  And here's the thread taking that post apart: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6637915
deleted 13y ago
[deleted]

bradleyjg 13y ago

Let's say Bob wants to communicate with Alice, and he doesn't want Sergey to be able to read his message, but Sergey writes the software that they want to use to communicate. In a peer to peer setup, Bob and Alice only need to trust a discrete piece of software they download from Sergey at a given point in time. Maybe that software is open source so they can audit it and thereafter have confidence in it. But if Sergey is instead releasing his software as a javascript program to be run in a web browser than they need to trust Sergey each and every time they run the program, because they are downloading the program anew each and every time they want to use it. Even if Sergey is a stand up guy, this setup means that the government can force him to break his promise at any time, whereas if he had put out a discrete set of software versions, particularly if they were open source with a public source control, he could plausibly tell the government that what they were asking was impossible.

igravious 13y ago
So the question becomes one of modifying the browser Javascript delivery mechanism to allow a more secure & discrete versions channel that would require user intervention. Or could there be another possible way?
- bradleyjg 13y ago
  There's already a mechanism in place for that in the form of javascript plugins/extensions/scripts which have to be explicitly installed. There's still problems because downloaded javascript can run in the same context and subvert the installed javascript. I believe tptacek has written a blog post elaborating on the problems with that. In a larger sense, I would push back against the web browser as a general purpose OS. We already have a few battle tested OSes who designers have put great thought and effort into these problems. If you insist on javascript, there's even node.js programs, albeit generally installed outside of the usual OS specific mechanisms. If you insist on HTML/css for layout and javascript for programming, I believe there are toolkits based on webkit, chromium and IE that let you create a standalone program embedding the respective browser engines. You can even do what mailpile is doing and embed a web sever in your client application and use your web browser as a client to the client acting as a server (though this last seems a little Rube Golderg-esque to me). But in any event downloaded and installed like a full fledged program rather than treating the exercise as though you were going to a special website.