Hacker News Reader

Comment by dmix | Hacker News Reader

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

View on HN

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

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?

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.

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.

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.

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.

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.

> Yes, but just because it can be mitigated doesn't mean that it is mitigated.

Sure, but I just want to point to the fact that this is a solvable problem. A lot of people talk as if it is some sort of insurmountable obstacle, whereas I think responsible programmers can solve it and move on.

You're arguing for a theoretical world, we're arguing from a practical one. I've spent enough time down in the trenches finding attacks in extremely well-reviewed code, that adding a massive new attack surface is not a thrilling proposition.

Well, I guess you're just slightly more pessimistic and I'm slightly more optimistic. I respect your viewpoint, though. :-)

The smiley face in that comment is doing a lot of work.

I'm a really optimistic type, really. Optimistic to the annoyance of some people. But in the case of security and cryptology there does not exist a choice between optimism and pessimism, but a choice between sharp eyed paranoia and wilful ignorance.

A defence is always only as strong as the weakest link, and an attacker usually has all the time in the world to find and exploit it.

Optimism has no place here.

In the context of the GP (attack by someone with access to the CA infrastructure) you can't trust "signed" plugins either.

Reply on news.ycombinator.com