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.
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)
> - 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
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.
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)
