This is an authentication and a trust issue. JS crypto does not solve this at all.
> What about the fact that the server can still read your data? Again, how can you trust the server with your plaintext if you can't trust it to serve you good JS crypto code?
If you don't trust the server, why are you sending it the data? And how is JS crypto any better?
If you're trying to bash SSL to promote JS crypto as a better alternative, you should probably choose problems that JS crypto doesn't also have.
> There have been attempts to mitigate this problem in JS crypto anyway, using browser plugins that perform integrity checks.
This isn't JS crypto. This is "browser plugin crypto, that we're choosing to compromise by tacking on a huge JS part that someone can backdoor".
JS crypto remains better since there exists techniques to verify the crypto, and the server does not receive plaintext.
> This isn't JS crypto. This is "browser plugin crypto, that we're choosing to compromise by tacking on a huge JS part that someone can backdoor".
That's ridiculous. Integrity checks exist for many crypto-systems, don't perform crypto - they are an extension.
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".
...
When it comes to security, that is actually a negative.
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 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.
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.)
> 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?
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.
> And this then brings us back to the earlier point, which is why not just use the plugin for crypto in the first place?
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.
When a server serves you a page, it basically owns that context. Crypto can secure further communication between that page and the server (via SSL), but there's basically no room to hide something from the server, and if there was that would probably be considered a browser bug at some level. If the server does not receive plaintext, which a network-level analysis may say it does not, it is only because the server has graciously consented to not receive some plaintext, not because you have actually somehow built a webpage that can prevent the server from getting that plaintext. One tweak to the server, it serves slightly different JS and offers a slightly different API and bam, it's getting plaintext.
Web pages just don't have enough identity of their own to do anything like this separate from the server, without further extensions (which is why the topic of plugins keeps coming up).
Absolutely, to the point that it's ridiculous to compare it to client-side Javascript.
Comodo was breached and the certificates were revoked using the theoretically-sound, tested, and implemented PKI solution.
Weeeellll actually... Mozilla, Google, MS had to rush out a code patch to manually blacklist the fraudulent certs. Revocation checking is implemented so weakly in browsers and other HTTPS clients that it just doesn't work when it comes down to it.
Of course, the browser Javascript doesn't have any problems of weak revocation checking. It's simply altogether unauthenticated in the first place!
Furthermore, and most importantly, by using SSL/TLS, the data being sent by the browser to the server is encrypted as it passes through the network, but however remains readable by the server when it reaches it. Whereas with client-side JS crypto, the server cannot read the sensitive data.
This is a shortcoming in the argument made in the article, because it wrongly assumes that we would always want the server to decrypt our data.
I am not saying JS does solve this, but SSL doesn't, and it isn't even meant for that use case.
Do you trust them?
If so, why not have them do the encryption rather than relying on untrusted code to do it?
It can mean it comes from a source your trust.
Or it can mean you trust it to do something that you know and only that.
Which one do you refer?
The only way to verify behavior of codes is to do source auditing yourself. Which is what our average Joes would not be able to do himself anyway, so you get back having to trust entities instead of behavior. Which in that case, we are either get back to CAs or trusting individual certs directly.