5 ms·

It's not just a malicious server, an attacker can put himself between you and the perfectly secure server and then send you whatever javascript code he likes, t

It's not just a malicious server, an attacker can put himself between you and the perfectly secure server and then send you whatever javascript code he likes, that's the whole point. And yes, since it cannot be made secure, it should be outright dismissed.

M4v3R 12y ago
How exactly can he do that when all the traffic is encrypted via SSL? And to address the quote from the article that you don't need JS Crypto if you're using SSL/TLS. It's a wrong assumption, there are still uses for it. It adds more security to the user data which is encrypted before it hits the server. A hacker owning the server at some point won't be able to get the data. He could, in theory, plant a exploit to collect user passwords (as they log in) but it's unlikely that it wouldn't get noticed very quickly.
- Tloewald 12y ago
  I think the problem is when using JavaScript crypto instead of TLS, not in addition to. The article should probably address this specifically.
  - lloeki 12y ago
    Not just: any attack that can inject arbitrary code in a web page (e.g XSS attacks), and other crypto oriented attack due to lack of serious primitives being available (e.g timing attacks or attacks on the RNG)
    - Tloewald 12y ago
      Sure but I'm not clear on how this would be made worse by in-browser crypto.
      - deleted 12y ago
        [deleted]
kachnuv_ocasek 12y ago
That's not a problem with JavaScript, though. In that case, he could send whatever he wanted.
- marcosdumay 12y ago
  He can not send a browser plugin, nor can he send desktop software. The only (dangerous) thing an attacker can send on this case is Javascript.
  - kachnuv_ocasek 12y ago
    Of course he can send you executable content right away. He can also send you to a page and instruct you to download something.
lloeki 12y ago
> It's not just a malicious server The author effectively dismisses the point being about a malicious server: especially with "Just use the SSL", because, well, if you're landed on the server, SSL means squat. The author is concerned about: - the unavailability of secure functions necessary for crypto (as simple as RNG, as useful as an AES call, or as complex as a full-blown PGP API with transparent, ad-hoc key management) in browsers - the unavailability of a secure, non-monkey-patchable runtime environment for JS crypto code to execute in, guaranteeing one can use the aforementioned functions as intended - the vulnerability of the code as content in the channel itself (when not using SSL) or in the browser itself (XSS and all) All of those being legitimate causes of concerns (IOW in crypto world, gaping holes rendering client-side JS crypto untrustable)
- cwmma 12y ago
  > - the unavailability of a secure, non-monkey-patchable runtime environment for JS crypto code to execute in, guaranteeing one can use the aforementioned functions as intended That one at least can be dealt with by web workers
  - joshuacc 12y ago
    Worker = myMaliciousWorkerImpersonatorFunction;

M4v3R 12y ago

How exactly can he do that when all the traffic is encrypted via SSL? And to address the quote from the article that you don't need JS Crypto if you're using SSL/TLS. It's a wrong assumption, there are still uses for it. It adds more security to the user data which is encrypted before it hits the server. A hacker owning the server at some point won't be able to get the data. He could, in theory, plant a exploit to collect user passwords (as they log in) but it's unlikely that it wouldn't get noticed very quickly.

Tloewald 12y ago
I think the problem is when using JavaScript crypto instead of TLS, not in addition to. The article should probably address this specifically.
- lloeki 12y ago
  Not just: any attack that can inject arbitrary code in a web page (e.g XSS attacks), and other crypto oriented attack due to lack of serious primitives being available (e.g timing attacks or attacks on the RNG)
  - Tloewald 12y ago
    Sure but I'm not clear on how this would be made worse by in-browser crypto.
    - deleted 12y ago
      [deleted]

kachnuv_ocasek 12y ago

That's not a problem with JavaScript, though. In that case, he could send whatever he wanted.

marcosdumay 12y ago
He can not send a browser plugin, nor can he send desktop software. The only (dangerous) thing an attacker can send on this case is Javascript.
- kachnuv_ocasek 12y ago
  Of course he can send you executable content right away. He can also send you to a page and instruct you to download something.

lloeki 12y ago

> It's not just a malicious server The author effectively dismisses the point being about a malicious server: especially with "Just use the SSL", because, well, if you're landed on the server, SSL means squat. The author is concerned about: - the unavailability of secure functions necessary for crypto (as simple as RNG, as useful as an AES call, or as complex as a full-blown PGP API with transparent, ad-hoc key management) in browsers - the unavailability of a secure, non-monkey-patchable runtime environment for JS crypto code to execute in, guaranteeing one can use the aforementioned functions as intended - the vulnerability of the code as content in the channel itself (when not using SSL) or in the browser itself (XSS and all) All of those being legitimate causes of concerns (IOW in crypto world, gaping holes rendering client-side JS crypto untrustable)

cwmma 12y ago
> - the unavailability of a secure, non-monkey-patchable runtime environment for JS crypto code to execute in, guaranteeing one can use the aforementioned functions as intended That one at least can be dealt with by web workers
- joshuacc 12y ago
  Worker = myMaliciousWorkerImpersonatorFunction;