3 ms·

SSL/TLS is a better solution. I find it ridiculous you suggest that browser-based JS is better, frankly. Comodo was breached and the certificates were revoked u

by adgar 15y ago

SSL/TLS is a better solution. I find it ridiculous you suggest that browser-based JS is better, frankly. Comodo was breached and the certificates were revoked using the theoretically-sound, tested, and implemented PKI solution. While you do well to point to existing attempts to work around JavaScript's deficiencies, it's genuinely surprising you could say they exceed the capabilities of SSL/TLS.

magikarp 15y ago
What about sslstrip? What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? 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? There have been attempts to mitigate this problem in JS crypto anyway, using browser plugins that perform integrity checks.
- jbri 15y ago
  > What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? 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".
  - magikarp 15y ago
    > 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
lawnchair_larry 15y ago
SSL/TLS doesn't solve this problem noted by GP: 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.
- jbri 15y ago
  In fact, any "solution" that relies on the server giving you code to prevent the server from reading your data is inherently broken.
  - magikarp 15y ago
    I disagree, on the grounds that the code can always be verified.
    - jbri 15y ago
      By whom? Do you trust them? If so, why not have them do the encryption rather than relying on untrusted code to do it?
    - fadzlan 15y ago
      Verified can mean a lot of things. 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.
marshray 15y ago
SSL/TLS is a better solution. 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!

by adgar 15y ago

magikarp 15y ago

What about sslstrip? What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? 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? There have been attempts to mitigate this problem in JS crypto anyway, using browser plugins that perform integrity checks.

jbri 15y ago
> What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? 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".
- magikarp 15y ago
  > 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

lawnchair_larry 15y ago

SSL/TLS doesn't solve this problem noted by GP: 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.

jbri 15y ago
In fact, any "solution" that relies on the server giving you code to prevent the server from reading your data is inherently broken.
- magikarp 15y ago
  I disagree, on the grounds that the code can always be verified.
  - jbri 15y ago
    By whom? Do you trust them? If so, why not have them do the encryption rather than relying on untrusted code to do it?
  - fadzlan 15y ago
    Verified can mean a lot of things. 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.

marshray 15y ago

SSL/TLS is a better solution. 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!