> the vuln was not that the JS was bad or untrustworthy, but that the passphrase was sent to the server.
Which is one of the most commonly cited vulnerabilities with web-based crypto. The fact that no JS was involved doesn't really change anything.
> If the entire connection to the server is secure, and the JS is loaded from the secure server and is auditable/checksummed, then the risk is minimal. You either trust the code or you get out.
I assume you're referring to client-side, JS-based encryption. The problem is that the server can always slip a backdoor into the webpage, and your browser will dutifully execute it. It doesn't matter if the JS is sent via SSL. A compromised server can deliver compromised JS, and SSL provides no protection against that.
You can't practically audit for this. You could theoretically read the JavaScript. But performing a thorough audit on a cryptosystem is a big undertaking. And then how do you know it hasn't changed the next time you visit the page? You mentioned checksums, but how are you going to do that? Are you going to manually MD5 the JS file on every visit?
Even if you did, the JS file is just one of many ways a compromised server can backdoor your browser. For example, we recently learned about HTML5 timing attacks (http://www.contextis.com/files/Browser_Timing_Attacks.pdf). And that's just the tip of the iceberg. Checksums aren't going to tell you if these sorts of things are happening.
A compromised server can compromise any data entered into webpages it serves. There is no known way around this.
Which is one of the most commonly cited vulnerabilities with web-based crypto. The fact that no JS was involved doesn't really change anything.
> If the entire connection to the server is secure, and the JS is loaded from the secure server and is auditable/checksummed, then the risk is minimal. You either trust the code or you get out.
I assume you're referring to client-side, JS-based encryption. The problem is that the server can always slip a backdoor into the webpage, and your browser will dutifully execute it. It doesn't matter if the JS is sent via SSL. A compromised server can deliver compromised JS, and SSL provides no protection against that.
You can't practically audit for this. You could theoretically read the JavaScript. But performing a thorough audit on a cryptosystem is a big undertaking. And then how do you know it hasn't changed the next time you visit the page? You mentioned checksums, but how are you going to do that? Are you going to manually MD5 the JS file on every visit?
Even if you did, the JS file is just one of many ways a compromised server can backdoor your browser. For example, we recently learned about HTML5 timing attacks (http://www.contextis.com/files/Browser_Timing_Attacks.pdf). And that's just the tip of the iceberg. Checksums aren't going to tell you if these sorts of things are happening.
A compromised server can compromise any data entered into webpages it serves. There is no known way around this.