3 ms·

The worst problem nowadays is how to make sure that your HTTPS connection is not MITMed. For most low to medium risk profiles HTTPS is safe enough. However in

The worst problem nowadays is how to make sure that your HTTPS connection is not MITMed. For most low to medium risk profiles HTTPS is safe enough. However in these cases in-browser encryption is rarely needed. For the threat model applications like Cryptocat faces, the danger for a targeted attack by someone with access to the CA infrastructure is not negligible. So if can trust the server with your data, you don't need JS cryptology. If you can't trust the server, how can you trust the JS it sends?

daeken 13y ago
> If you can't trust the server, how can you trust the JS it sends? This is the fundamental issue here. The trust model is purely, irrevocably broken. This isn't something you can paper over.
dmix 13y ago
> So if can trust the server with your data, you don't need JS cryptology. If you can't trust the server, how can you trust the JS it sends? He address that with using chrome plugins and code verifiers. Not the ideal or most convenient solution obviously. But you also can't assume the JS is hosted and delivered by the same server the data is being transmitted through. JS is extremely portable.
- daeken 13y ago
  > He address that with using plugins and verifiers. Not the ideal solution obviously. As noted in the second point of my response in the root of the thread, this isn't just a non-ideal solution, it's a non-solution. It doesn't solve the trust boundary issues inherent here.
  - magikarp 13y ago
    Aren't those trust boundary issues also present in every other piece of downloadable software, such as Tor for example? When you download a signed plugin, what's the difference from downloading Tor?
    - daeken 13y ago
      In theory, yes. There's nothing inherently more secure about Tor than an app running in the browser. However, XSS attacks are everywhere, it's trivial for servers to shoot code down to the client to evaluate, etc. In practice, an app doing crypto on your desktop is fundamentally very different from a web app doing it, even if that's signed and isolated.
      - magikarp 13y ago
        Okay. But XSS is class of bugs that has nothing to do with code delivery, and that is quite possible to mitigate. So overall, the problem of code delivery is still addressed to a notable (if not complete) extent with the use of downloadable signed browser apps.
        0x0 13y ago
        Huh? Maybe I misunderstand what you're going on about, but if you can XSS in javascript, you can certainly change the meaning of even signed code - just hijack Object.prototype.constructor or similar.
        magikarp 13y ago
        That may very well be the case, but isn't this a solvable problem? Just like apps made in C need to be protected against buffer overflows, apps made in JS need to be protected against XSS. Both are reasonable threats that can be mitigated.
        wglb 13y ago
        Consider the fact that XSS is some other part of the application that the reviewed crypto plugin JS is part of has an XSS in it. Yes, but just because it can be mitigated doesn't mean that it is mitigated.
        magikarp 13y ago
- ams6110 13y ago
  In the context of the GP (attack by someone with access to the CA infrastructure) you can't trust "signed" plugins either.

daeken 13y ago

> If you can't trust the server, how can you trust the JS it sends? This is the fundamental issue here. The trust model is purely, irrevocably broken. This isn't something you can paper over.

dmix 13y ago

> So if can trust the server with your data, you don't need JS cryptology. If you can't trust the server, how can you trust the JS it sends? He address that with using chrome plugins and code verifiers. Not the ideal or most convenient solution obviously. But you also can't assume the JS is hosted and delivered by the same server the data is being transmitted through. JS is extremely portable.

daeken 13y ago
> He address that with using plugins and verifiers. Not the ideal solution obviously. As noted in the second point of my response in the root of the thread, this isn't just a non-ideal solution, it's a non-solution. It doesn't solve the trust boundary issues inherent here.
- magikarp 13y ago
  Aren't those trust boundary issues also present in every other piece of downloadable software, such as Tor for example? When you download a signed plugin, what's the difference from downloading Tor?
  - daeken 13y ago
    In theory, yes. There's nothing inherently more secure about Tor than an app running in the browser. However, XSS attacks are everywhere, it's trivial for servers to shoot code down to the client to evaluate, etc. In practice, an app doing crypto on your desktop is fundamentally very different from a web app doing it, even if that's signed and isolated.
    - magikarp 13y ago
      Okay. But XSS is class of bugs that has nothing to do with code delivery, and that is quite possible to mitigate. So overall, the problem of code delivery is still addressed to a notable (if not complete) extent with the use of downloadable signed browser apps.
      - 0x0 13y ago
        Huh? Maybe I misunderstand what you're going on about, but if you can XSS in javascript, you can certainly change the meaning of even signed code - just hijack Object.prototype.constructor or similar.
        magikarp 13y ago
        That may very well be the case, but isn't this a solvable problem? Just like apps made in C need to be protected against buffer overflows, apps made in JS need to be protected against XSS. Both are reasonable threats that can be mitigated.
        wglb 13y ago
        Consider the fact that XSS is some other part of the application that the reviewed crypto plugin JS is part of has an XSS in it. Yes, but just because it can be mitigated doesn't mean that it is mitigated.
        magikarp 13y ago
ams6110 13y ago
In the context of the GP (attack by someone with access to the CA infrastructure) you can't trust "signed" plugins either.