3 ms·

Yes, you need to trust me. I'd argue it's easier to trust me if the crypto is happening on the client since if I change it, I could be caught. The probability

Yes, you need to trust me. I'd argue it's easier to trust me if the crypto is happening on the client since if I change it, I could be caught. The probability of being caught in any one instance is very low but over many instances is high. Would you make the same argument for native application? Unless you read the source code every time you upgrade, you're exposed to the same risk. cperciva did an inadvertent real world experiment on this by making an error during a refactoring of Tarsnap and it took 19 months for a subtle crypto bug to be noticed.

e1ven 13y ago
If you changed it globally, you might be noticed next time someone did an audit, which I suspect would be rare. If you added a backdoor on the server that said "If userid == e1ven{crypto.js = plaintext.js}" it would be much harder to detect. Hushmail did something similar with a modified version of it's Java applet, back a few years ago- http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ My point isn't that you should never trust webapps - It's that doing the processing in JS, or on the server, doesn't CHANGE the threat-model. In both scenerios, I need to trust you an identical amount, so there's no security advantage do doing the crypto on the client side.
- pyre 13y ago
  Well, it's slightly different. Every person might not check every single time, but it would be possible to do something like write a browser plugin (or setup some sort of automated system) to check what was going on since the execution is happening client-side. I made sure to emphasize 'slightly' because this could just trigger an arms race to getting around detection. You might be safe if you kept your detection methods a secret (and only personally used them). On the other hand, if the detection methods were used/deployed on a wide scale, then anyone trying to compromise you would just work around the detection.
  - tptacek 13y ago
    What would that browser plugin check for? How would you write it?
    - pyre 13y ago
      - Check signature of the incoming JavaScript against known good versions. - Check the signature of the HTML page against known good versions. - Check that the information posted back to the server 'looks encrypted' vs. plaintext[1]. - Check the external resources that the page is requesting. Is it grabbing Javascript files that are unexpected (e.g. trying to serve up a known-good version of crypto.js, but then overwrite its methods with another Javascript file). I'm not sure if many of these things would be possible in Chrome/Chromium, but probably in Firefox. [1] Obviously 'looking encrypted' isn't some sort of binary decision, but I'm guessing there is some amount of checking you could do to see how closely it resembles random noise. If you sent random noise, and it wasn't encrypted, it would probably pass this check, but most people trying to protect something are probably sending something that won't trip this 'alarm.' This is not fool-proof, but adds a layer of protection when used with other things.
      - danielweber 13y ago
        Once you have a plugin to check all that stuff, why not have the plugin do the crypto, and just skip the javascript?
        pyre 13y ago
        That's obviously the better solution. I'm just being pedantic about the crypto happening in the browser vs. on the server.
      - tptacek 13y ago
        "Looks encrypted" isn't useful; encryption under a known key or with unsafe parameters "looked encrypted" too. Are you sure you've captured every case that could influence what functions are bound to what symbols in the JS runtime?
tptacek 13y ago
Once Colin noticed he had the wrong nonce value for his CTR mode encryption, he was able to fix it once, tell users to upgrade, and nobody ever had to consider it again. On the other hand, every single time someone loads your page, the server has the opportunity to surreptitiously add a tiny snippet of Javascript that would fixate the CCM IV your code generates. Nobody would ever notice that, and you could do it selectively (or, more likely, based on a court order).
- absherwin 13y ago
  You're implicitly applying different threat models to browser-downloaded vs. alternatively downloaded code. If the maintainer of JS code make a mistake and fixes it in future versions, there's no need to worry about it anymore either. However, every time I upgrade I'm just as much at risk from someone attacking either my connection or having attacked the server. So to believe it's more secure, you have to believe those things are easier to do in the context of a web application.

e1ven 13y ago

If you changed it globally, you might be noticed next time someone did an audit, which I suspect would be rare. If you added a backdoor on the server that said "If userid == e1ven{crypto.js = plaintext.js}" it would be much harder to detect. Hushmail did something similar with a modified version of it's Java applet, back a few years ago- http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ My point isn't that you should never trust webapps - It's that doing the processing in JS, or on the server, doesn't CHANGE the threat-model. In both scenerios, I need to trust you an identical amount, so there's no security advantage do doing the crypto on the client side.

pyre 13y ago
Well, it's slightly different. Every person might not check every single time, but it would be possible to do something like write a browser plugin (or setup some sort of automated system) to check what was going on since the execution is happening client-side. I made sure to emphasize 'slightly' because this could just trigger an arms race to getting around detection. You might be safe if you kept your detection methods a secret (and only personally used them). On the other hand, if the detection methods were used/deployed on a wide scale, then anyone trying to compromise you would just work around the detection.
- tptacek 13y ago
  What would that browser plugin check for? How would you write it?
  - pyre 13y ago
    - Check signature of the incoming JavaScript against known good versions. - Check the signature of the HTML page against known good versions. - Check that the information posted back to the server 'looks encrypted' vs. plaintext[1]. - Check the external resources that the page is requesting. Is it grabbing Javascript files that are unexpected (e.g. trying to serve up a known-good version of crypto.js, but then overwrite its methods with another Javascript file). I'm not sure if many of these things would be possible in Chrome/Chromium, but probably in Firefox. [1] Obviously 'looking encrypted' isn't some sort of binary decision, but I'm guessing there is some amount of checking you could do to see how closely it resembles random noise. If you sent random noise, and it wasn't encrypted, it would probably pass this check, but most people trying to protect something are probably sending something that won't trip this 'alarm.' This is not fool-proof, but adds a layer of protection when used with other things.
    - danielweber 13y ago
      Once you have a plugin to check all that stuff, why not have the plugin do the crypto, and just skip the javascript?
      - pyre 13y ago
        That's obviously the better solution. I'm just being pedantic about the crypto happening in the browser vs. on the server.
    - tptacek 13y ago
      "Looks encrypted" isn't useful; encryption under a known key or with unsafe parameters "looked encrypted" too. Are you sure you've captured every case that could influence what functions are bound to what symbols in the JS runtime?

tptacek 13y ago

Once Colin noticed he had the wrong nonce value for his CTR mode encryption, he was able to fix it once, tell users to upgrade, and nobody ever had to consider it again. On the other hand, every single time someone loads your page, the server has the opportunity to surreptitiously add a tiny snippet of Javascript that would fixate the CCM IV your code generates. Nobody would ever notice that, and you could do it selectively (or, more likely, based on a court order).

absherwin 13y ago
You're implicitly applying different threat models to browser-downloaded vs. alternatively downloaded code. If the maintainer of JS code make a mistake and fixes it in future versions, there's no need to worry about it anymore either. However, every time I upgrade I'm just as much at risk from someone attacking either my connection or having attacked the server. So to believe it's more secure, you have to believe those things are easier to do in the context of a web application.