3 ms·

> If you don't trust the server, why are you sending it the data? And how is JS crypto any better? JS crypto remains better since there exists techniques to ve

> If you don't trust the server, why are you sending it the data? And how is JS crypto any better? 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.

jbri 15y ago
> 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".
- magikarp 15y ago
  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.
  - jbri 15y ago
    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.
    - magikarp 15y ago
      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.
      - jbri 15y ago
        ...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.
        magikarp 15y ago
        > 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.)
        jbri 15y ago
        Why is a plugin trustworthy where the root CAs are not?
        magikarp 15y ago
        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.
tptacek 15y ago
What cryptosystem are you talking about in which integrity checking is an optional feature?
jerf 15y ago
For an unmodified and basically functional browser, in a way there isn't a "client" and a "server" context. There's only a server context. The client is actually a sandbox that has been designed to carefully partition off the server code from everything else that the server doesn't authorize, and hasn't got enough of an "identity" to be its own thing. A normal, correctly-functioning browser is designed to basically be an extension of the server in question, and there are no effective mechanisms for the client to have any state placed in it and fed back to that server that did not come from that server. Even when you type a comment into a text box and hit 'submit', what comes back to you is fed to you by the server in question. 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).

jbri 15y ago

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

magikarp 15y ago
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.
- jbri 15y ago
  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.
  - magikarp 15y ago
    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.
    - jbri 15y ago
      ...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.
      - magikarp 15y ago
        > 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.)
        jbri 15y ago
        Why is a plugin trustworthy where the root CAs are not?
        magikarp 15y ago
        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.

tptacek 15y ago

What cryptosystem are you talking about in which integrity checking is an optional feature?

jerf 15y ago

For an unmodified and basically functional browser, in a way there isn't a "client" and a "server" context. There's only a server context. The client is actually a sandbox that has been designed to carefully partition off the server code from everything else that the server doesn't authorize, and hasn't got enough of an "identity" to be its own thing. A normal, correctly-functioning browser is designed to basically be an extension of the server in question, and there are no effective mechanisms for the client to have any state placed in it and fed back to that server that did not come from that server. Even when you type a comment into a text box and hit 'submit', what comes back to you is fed to you by the server in question. 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).