Hacker News Reader

Comment by jbri | Hacker News Reader

> JS crypto remains better since there exists techniques to verify the crypto, and the server does not receive plaintext.

You are giving the plaintext to code that has (at best) the same trust level as the server itself.

What data is it safe to give to that code, that isn't safe to send (in a way that can't be mitm'd) to the server?

> That's ridiculous. Integrity checks exist for many crypto-systems, don't perform crypto - they are an extension.

I'm not sure what you're saying here - you might want to clarify exactly what you mean.

In doing so, perhaps you could tell me why you think "browser plugin validator + untrusted JS crypto code" is more secure or otherwise better than "browser plugin crypto with no JS".

View on HN

Don't get me wrong, browser plugin crypto probably works fine, but it's also possible to use a browser plugin to turn untrusted JS crypto code into trusted JS crypto code. The plus side of that is that the crypto code would still work without the plugin.

So your answer as to why JS+validator is better than a plugin doing crypto is that "it still appears to work fine even when the system is utterly broken".

...

When it comes to security, that is actually a negative.

Whether you consider it "utterly broken" or not without the validator depends on your trust of the server - similarly to HTTPS, which is vulnerable from the trust standpoint thanks to CA vulnerabilities.

Furthermore, it's possible to verify the code manually, although tediously, whereas a CA impersonation is perfectly transparent and very difficult to detect. The validator plugin usually does the job.

...and your trust of the network itself, unless you're using HTTPS in addition to your ad-hoc solution.

And vulnerabilities in the trust chain are not HTTPS vulnerabilities - they are trust chain vulnerabilities. It's straightforward to address them yourself simply by not trusting any CAs you don't trust.

> unless you're using HTTPS in addition to your ad-hoc solution.

Yes, I don't see why not.

> It's straightforward to address them yourself simply by not trusting any CAs you don't trust.

From that standpoint, we're assuming that everyone with a browser knows what a CA is and discerns between trustworthy CAs. I could equally say that it's straightforward for users to simply review the JavaScript code they don't trust - but the problem is that there exist many users who don't know how to review JavaScript and don't know what a CA is, and will just rely on what their browser tells them (which is where a plugin comes in handy.)

Why is a plugin trustworthy where the root CAs are not?

Simply because a plugin can be verified locally at length whereas a compromised CA can issue a fake cert that is very, very difficult to detect.

> but the problem is that there exist many users who don't know how to review JavaScript and don't know what a CA is, and will just rely on what their browser tells them (which is where a plugin comes in handy.)

> a plugin can be verified locally at length whereas a compromised CA can issue a fake cert that is very, very difficult to detect.

Which is it?

Either you're claiming that verifying a plugin is easier than not trusting CAs that you don't trust, or you're arguing two completely contrary positions.

edit:

And this then brings us back to the earlier point, which is why not just use the plugin for crypto in the first place?

Um, no.

The plugin is the same for all users - not everyone who downloads and runs GnuPG knows how to verify it - but some people might go as far as to either compile it from source or ever decompile it. If they find something suspicious, they will report it so that other people who have downloaded the software can be aware. Same thing goes for the plugin (except that the plugin is easier to verify than a compiled binary.)

When I talk about people who can't review JavaScript or CAs, I'm talking about the average computer user. I am not saying that "verifying a plugin is easier than not trusting CAs that you don't trust." The average computer user doesn't care about CAs or JavaScript.

My point remains: a plugin can be verified by others who have downloaded it - a compromised CA is extremely difficult to detect.

So once again:

> And this then brings us back to the earlier point, which is why not just use the plugin for crypto in the first place?

I'm sorry, but I've already answered this, as a reply to one of your own comments. Please scroll up.

And I disputed it, which is what lead us here. You are literally making a circular argument by trying to use your answer to support itself.

It's you who's being circular, sir.

To that point, what is the difference :-

1. just trusting the cert say for Amazon directly rather than trusting the chain of trust using CA (distrust all the root CA and just trust the cert of Amazon)

between

2. Trusting verified Javascript directly.

Reply on news.ycombinator.com