3 ms·

Well the integrity of the JS cryptosystem would be no worse than the integrity of the webapp itself. I understand that one cannot trust the JS crypto for handl

by deno 15y ago

Well the integrity of the JS cryptosystem would be no worse than the integrity of the webapp itself. I understand that one cannot trust the JS crypto for handling the private key and doing any singing & encryption because of the possibility of leaking information through side channels. That's why I was wondering if it'd be possible to use JS crypto in only one way — that is to verify messages against public key received through the secure channel. If the JS crypto only does verification, it wouldn't matter if the _public_ key is cached, as long as it can't be arbitrarily changed by another process. If the server is taken over or there's an XSS or other client-side vulnerability the bidirectional TLS would be similarly useless anyway.

tptacek 15y ago
It's not the "math" of the crypto that concerns me; it's the actual integrity of the code performing it. So for instance, if you're trying to do RSA operations in JS, how do you know that none of the bindings in the current Javascript runtime have been exposed to attacker-controllable content? How do you know nothing in the runtime was fed by cached content read over straight HTTP? Or from an HTTPS server that has a DOM corruption flaw?
- deno 15y ago
  If any of those things can be used to affect the crypto part, then they could be also used to affect the web application itself, in the first place. I'm only looking for the level of integrity, that I can get from launching the web application over HTTPS anyway.
  - tptacek 15y ago
    Is this a point that we're dancing around here? Let's resolve it: for the most part†, you're right: the things that break clientside JS web crypto are things that break (in various degrees) the web app itself. The problem with accepting this is that the point of clientside crypto is to inoculate users from the downside risks of the simple security flaws that most applications have. What's the point of sophisticated clientside crypto if it's undone by any trivial XSS flaw? † There are issues that damage clientside JS crypto that don't blow up the app itself, but they are not the core issues I'm concerning myself with here.
    - deno 15y ago
      I am mostly interested in replacing bi-directional TLS. There are things that need to be encrypted — authentication, any authorized operations, fetching authorized content — however the majority of content that application uses is public, so the encryption is very much redundant. Unfortunately I can't just bootstrap the application over secure channel and fetch any content over not secure channels, as it'd be trivial to then poison the application using the unencrypted communication. Take a Hacker News-like application: Let's say that news and comments can be accessed over unsecure channel and voting and authentication are performed over TLS. Even though the authorized operations are safe, the data could be poisoned over unsecure channel — for example the user-id could be manipulated and the user would end up voting securely for someone else's post. To mitigate it, all data would have to be fetched over secure channel. However currently this is all or nothing, by fetching public data over TLS, one has to pay the encryption tax — in both CPU time, as well as in disabling any caching middleware. Of course singing HTTP messages wouldn't be just TLS-light, since the messages could be stored and kept as an evidence that the webserver has produced such a message, which is different to TLS session-based guarantees, but it should be fine for what I need. This is why I was interested to know if such an approach would not degrade the security of the web application below what bi-directional TLS could offer. I suppose this is not the most exciting use for client-side cryptography right now… I think the web-application are increasingly going in the direction of reinventing Java applets anyway. There are few components that are needed for that and that will be gradually introduced: 1) Application that can be installed and launched locally (e.g. more sophisticated version of Chrome Webappstore). Once you have that, you basically have RPM in browser. 2) Capabilities system that controls what and how an application can access. All the pieces are already in there: web extensions, mobile apps, etc. 3) Pluggable storage to eliminate the need for storing data on the remote server. There is LocalStorage and IndexedDB already, now it's just a matter of time till Chrome adds Google Storage, Apple adds iCloud, Ubuntu adds UbuntuOne etc. Once you have that, the Java[Script] applets are basically back. With NaCL in the mix you could even actually run the JVM in the browser once again. So yeah, I think in the long run the client cryptography will come around. But for now I just wanted to make use of what's currently available.
      - tptacek 15y ago

by deno 15y ago

tptacek 15y ago

It's not the "math" of the crypto that concerns me; it's the actual integrity of the code performing it. So for instance, if you're trying to do RSA operations in JS, how do you know that none of the bindings in the current Javascript runtime have been exposed to attacker-controllable content? How do you know nothing in the runtime was fed by cached content read over straight HTTP? Or from an HTTPS server that has a DOM corruption flaw?

deno 15y ago
If any of those things can be used to affect the crypto part, then they could be also used to affect the web application itself, in the first place. I'm only looking for the level of integrity, that I can get from launching the web application over HTTPS anyway.
- tptacek 15y ago
  Is this a point that we're dancing around here? Let's resolve it: for the most part†, you're right: the things that break clientside JS web crypto are things that break (in various degrees) the web app itself. The problem with accepting this is that the point of clientside crypto is to inoculate users from the downside risks of the simple security flaws that most applications have. What's the point of sophisticated clientside crypto if it's undone by any trivial XSS flaw? † There are issues that damage clientside JS crypto that don't blow up the app itself, but they are not the core issues I'm concerning myself with here.
  - deno 15y ago
    I am mostly interested in replacing bi-directional TLS. There are things that need to be encrypted — authentication, any authorized operations, fetching authorized content — however the majority of content that application uses is public, so the encryption is very much redundant. Unfortunately I can't just bootstrap the application over secure channel and fetch any content over not secure channels, as it'd be trivial to then poison the application using the unencrypted communication. Take a Hacker News-like application: Let's say that news and comments can be accessed over unsecure channel and voting and authentication are performed over TLS. Even though the authorized operations are safe, the data could be poisoned over unsecure channel — for example the user-id could be manipulated and the user would end up voting securely for someone else's post. To mitigate it, all data would have to be fetched over secure channel. However currently this is all or nothing, by fetching public data over TLS, one has to pay the encryption tax — in both CPU time, as well as in disabling any caching middleware. Of course singing HTTP messages wouldn't be just TLS-light, since the messages could be stored and kept as an evidence that the webserver has produced such a message, which is different to TLS session-based guarantees, but it should be fine for what I need. This is why I was interested to know if such an approach would not degrade the security of the web application below what bi-directional TLS could offer. I suppose this is not the most exciting use for client-side cryptography right now… I think the web-application are increasingly going in the direction of reinventing Java applets anyway. There are few components that are needed for that and that will be gradually introduced: 1) Application that can be installed and launched locally (e.g. more sophisticated version of Chrome Webappstore). Once you have that, you basically have RPM in browser. 2) Capabilities system that controls what and how an application can access. All the pieces are already in there: web extensions, mobile apps, etc. 3) Pluggable storage to eliminate the need for storing data on the remote server. There is LocalStorage and IndexedDB already, now it's just a matter of time till Chrome adds Google Storage, Apple adds iCloud, Ubuntu adds UbuntuOne etc. Once you have that, the Java[Script] applets are basically back. With NaCL in the mix you could even actually run the JVM in the browser once again. So yeah, I think in the long run the client cryptography will come around. But for now I just wanted to make use of what's currently available.
    - tptacek 15y ago