Comment by utnick | Hacker News Reader

Comment by utnick | Hacker News Reader

I disagree that just because its possible for a malicious or comprimised server to send evil javascript, javascript crypto should not be done.

You have to analyze the threat model. Take the note taking webapp they use as an example. Without javascript crypto, anyone who breaks into the server can read everyones notes. Likewise, the FBI can get a warrant and have the owner of the web application turn over everyones notes.

If they do use javascript crypto, instead of just getting a warrant for the machine, the fbi has to convince the owner of the site to modify their source code to target an individual user to steal their key. That is a significant difference. Also, the victim user has to log in again for that attack to be successful, if they just used the server for a couple weeks and left, they are safe.

Likewise, an attacker who breaks into the server can't get a dump of all the notes in the system. They again have to modify the source code which could be noticed by the owners and users and takes some level of sophistication more than the average aim and shoot attacker

So is javascript security perfect right now? no... but that doesn't mean it should be dismissed

None of that requires JavaScript. You basically just described the Lavabit model, where user passwords were used to derive key material that was never stored on the server. If you trust the server to give you good client-side code barring exceptional cases, you might as well trust them to discard your password after use.

There is a difference in that Lavabit did have possession of the passwords and even plaintexts, however ephemerally.

As a legal matter, I don't believe there are any precedents for a vendor being forced to put a backdoor into a product they are distributing to others to be used in a place outside of the possession of the vendor.[1]

While still vulnerable to all sorts of technical problems as described in TFA, a website that treats the encryption/decryption code as a product they distribute to customers may be[2] subpoena-proof. Just because there are actions I can take to help the police gather evidence doesn't mean I can be compelled to do them. Turning over evidence in my possession is entirely different.

[1] I would love to hear one example of a vendor being legally compelled to backdoor a product. Things that definitely are not examples but people often say are examples include: Lavabit, Clipper, RSA's BSAFE, Hushmail, the NSA modifying hardware on their own, CALEA.

I would also, at this point, accept non-Internet analogues. Has a car dealer ever been required to install a GPS tag in a car they sell to a customer, for example?

[2] I would not recommend anyone volunteering to be the test case.

Law enforcement allegedly backdoored Hushmail. Why do you think that isn't a valid example?

I know Hushmail said "we could end up having to ship out a compromised Java executable" but did that ever happen? I think they shot off their mouth thinking only of "well, I guess the government can make us do anything, right?" and deciding that was how the government could do it.

edit took out mistake about BC versus Canada

EDIT To be clear, I'm questioning whether Hushmail was ever actually required to give a backdoored version of their code to anyone. This is opposed to having to give over information that was or would be within their servers at some point, even if Hushmail had to modify their systems to keep it.

> So is javascript security perfect right now? no... but that doesn't mean it should be dismissed

It does mean it should be dismissed. "Not perfect" crypto means broken crypto.

Nothing is perfect. Various crypto algorithms have minor weaknesses but we still use them. Your OSS compiler could have been compromised decades ago ("On Trusting Trust"). The NSA could have hidden a backdoor in every CPU.

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.

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.

I think the problem is when using JavaScript crypto instead of TLS, not in addition to. The article should probably address this specifically.

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)

Sure but I'm not clear on how this would be made worse by in-browser crypto.

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

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.

Of course he can send you executable content right away. He can also send you to a page and instruct you to download something.

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

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

Worker = myMaliciousWorkerImpersonatorFunction;

Reply on news.ycombinator.com