5 ms·

It is ridiculous that even in light of the COMODO HTTPS hack, the writer would go as far as to say that SSL/TLS is a better solution. The writer also ignores t

It is ridiculous that even in light of the COMODO HTTPS hack, the writer would go as far as to say that SSL/TLS is a better solution. The writer also ignores that there are potential solutions to many of the problems pointed out: In case of random number generation, check out seedrandom: http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html http://davidbau.com/archives/2010/01/30/random_seeds_coded_h... And while it's true that the server may always send "poisoned" JavaScript code, projects that heavily depend on such code, such as Cryptocat, now ship browser plugins that perform integrity checks on the code for you: https://chrome.google.com/webstore/detail/dlafegoljmjdfmhgoeojifolidmllaie https://chrome.google.com/webstore/detail/dlafegoljmjdfmhgoe... 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. If the writer does not trust the server to send correct JS code, how can he trust it with the sensitive data itself, in plaintext, which is what he is doing by using SSL/TLS? As I mentioned above, there exist browser plugins for a few projects to verify the integrity of the JS crypto they use.

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".
- 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!
tptacek 15y ago
A user looking at the "cryptocat session verifier plugin" has to think to herself, "What is this thing verifying? Is it just checking a digest of the Javascript files? How does it know if the CSS files have surreptitious Javascript in them that negates the crypto?" Which is funny, because if cryptocat just required a browser extension that implemented all the crypto, it wouldn't need to verify anything at all. What was the point of Javascript crypto at all, if you're just going to push an extension onto people? Your unease with SSL/TLS and its X509 PKI is entirely orthogonal to whether Javascript crypto works or does not work. Wanting an alternative to TLS does not give you an alternative to TLS. It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".
- magikarp 15y ago
  Actually, in the case of that particular plugin, every bit of code, including CSS, JS, and HTML, are verified. > It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked". It's hilarious how you completely ignore the much more pressing issues in HTTPS that I've pointed out. The server can read plaintext in the case of HTTPS, which is mitigated in JS crypto; not to mention that things such as SSLStrip and the COMODO hack have put many chinks in HTTPS's armour - HTTPS is a technology that derives a lot of trust from being able to authenticate the server, whereas we've seen authorities such as China create entirely passable fake certs to fool dissidents.
  - tptacek 15y ago
    When the server is providing the client with its crypto code, the server can read the plaintext no matter what. I don't like these bullshit false promises. If you are worried that China may own one of the root certs in your browser, remove the certs you don't trust. Hell, remove all the certs. Every mainstream browser allows you to do that. In most of them, you can even set up permanent exceptions for Amazon.com after you strip your certs out. Meanwhile, HTTPS/TLS has over a decade of the most intensive study anywhere on the planet, and your favorite half-assed ad-hoc bespoke random "crypto-cat" scheme... does not.

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

tptacek 15y ago

A user looking at the "cryptocat session verifier plugin" has to think to herself, "What is this thing verifying? Is it just checking a digest of the Javascript files? How does it know if the CSS files have surreptitious Javascript in them that negates the crypto?" Which is funny, because if cryptocat just required a browser extension that implemented all the crypto, it wouldn't need to verify anything at all. What was the point of Javascript crypto at all, if you're just going to push an extension onto people? Your unease with SSL/TLS and its X509 PKI is entirely orthogonal to whether Javascript crypto works or does not work. Wanting an alternative to TLS does not give you an alternative to TLS. It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".

magikarp 15y ago
Actually, in the case of that particular plugin, every bit of code, including CSS, JS, and HTML, are verified. > It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked". It's hilarious how you completely ignore the much more pressing issues in HTTPS that I've pointed out. The server can read plaintext in the case of HTTPS, which is mitigated in JS crypto; not to mention that things such as SSLStrip and the COMODO hack have put many chinks in HTTPS's armour - HTTPS is a technology that derives a lot of trust from being able to authenticate the server, whereas we've seen authorities such as China create entirely passable fake certs to fool dissidents.
- tptacek 15y ago
  When the server is providing the client with its crypto code, the server can read the plaintext no matter what. I don't like these bullshit false promises. If you are worried that China may own one of the root certs in your browser, remove the certs you don't trust. Hell, remove all the certs. Every mainstream browser allows you to do that. In most of them, you can even set up permanent exceptions for Amazon.com after you strip your certs out. Meanwhile, HTTPS/TLS has over a decade of the most intensive study anywhere on the planet, and your favorite half-assed ad-hoc bespoke random "crypto-cat" scheme... does not.