4 ms·

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 lo

• 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
      This is generally a terrible idea. TLS 1.2 is the product of almost 20 years of sustained attention and adversarial testing effort, 20 years of missteps, 20 years of design decisions argued over by people clearly not limited to but including some of the best cryptosystem thinkers in the field, and it still has missteps in it. The idea of replacing it with ad-hoc encryption at the application layer carries with it the notion that the basic problem of "taking some bundle of application data and securing it so that it is encrypted in flight" is somehow simple, and that TLS 1.2 is overkill for it. But that's not true. To a significant extent, everything TLS 1.2 does that you don't do is a vulnerability in your system. You won't see it or fully understand it; extremely competent people have gone years staring terrible vulnerabilities in TLS in the face, even after those flaws were pointed out to them, and let them pass because the real-world practical impact wasn't obvious at the time. And this is all before you get to the point where, to avoid the overhead and complexity and inflexibility (and whatnot) of TLS 1.2, you choose to build your cryptosystem in the most hostile possible environment for cryptography: the language runtime where no operation, function, or binding can be trusted, where every symbol table is potentially corrupted by any of 10s of content sources, many of them under the control of attackers, in a runtime that is being aggressively redesigned, optimized, JIT'd, cached, and transformed for performance. So you can see that this goal puts you out in the wilderness on two vectors: one of attempting to start from scratch on secure transport protocols, when 20 years has shown us that the simplest service models for secure transport are surprisingly hard; and the other vector being "trying to implement secure crypto in a language environment that's hostile to the concept". Skip it. Work on something that will make people's lives better in the immediacy, instead.
      • deno 15y ago
        > The idea of replacing it with ad-hoc encryption at the application layer Yes, I understand that this would be a terrible idea. That is why I only intended to verify signed, public content using static key. I don't indent do any encryption in client-side JS, not even to generate session keys!
        • tptacek 15y ago