5 ms·

Unless I have read this wrong cryp.sr uses Javascript to encrypt/decrypt data right? In which case "host proof" is really only a marketing term. This has been

by ErrantX 16y ago

Unless I have read this wrong cryp.sr uses Javascript to encrypt/decrypt data right? In which case "host proof" is really only a marketing term. This has been discussed a couple of times here in the past week or so (mostly by tpatcek) and, really, there is no way to effectively secure data just with Javascript. These sorts of apps have some use - so long as users understand the flaws involved and trust the server owner (and their browser).

cortesi 16y ago
This is not correct, on a few fronts. It _is_ possible to secure data with just Javascript (with care), and "host proof" describes a design philosophy that has real meaning - Google the term, and look at excellent commercial projects like Clipperz (who use "zero knowledge" as a synonym for "host proof"). You can also read this post I wrote when I took my first skeptical look at the idea. It discusses how and why the host-proof idea could work, and finds some flaws in Clipperz and PassPack, the two most prominent "host-proof" commercial apps: http://corte.si/posts/security/hostproof.html http://corte.si/posts/security/hostproof.html I should note that Clipperz has now addressed all the points I raised in my post. The "host-proof" idea has been around for a while, but is really just in its infancy. There's a lot of work to be done, but the idea is both important and promising.
- ErrantX 16y ago
  Yes I understand your point; but it still comes down to trusting to server (which is fine, but it is something "host proof" doesn't really encourage IMO). The verification is all very well and good; but you have to either verify the code each time (a pain) or trust the server between the times you do review the code. For most people reviewing the code is impractical. We discussed all this before in great detail; I'll try to dig out the threads. But from a security perspective this sort of stuff has a use, but not for things you really must keep secure. As a start: because the code of the app is sent "over the wire" with some regularity it is trivial to intercept and modify it.
  - cortesi 16y ago
    Again, you should read more on this issue before you criticize the idea in absolute terms. Yes, verification is necessary, which is why I wrote a browser addon that can do hash-based verification of the application every time the page is loaded (described here: http://corte.si/posts/security/crypsr.html http://corte.si/posts/security/crypsr.html, with links to the github project), and which is why cryp.sr has application hashes published with every modification. Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat. The techniques are still clunky - but that's because it's very early days, and we're still developing the tools and techniques to make things seamless. The basic idea, however, is entirely sound, and increasingly important.
    - gloob 16y ago
      Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat. I'll admit up-front that I have only a cursory knowledge of security topics, but it was my understanding that SSL prevents the traffic from being read, but not from being modified. Am I incorrect in this belief?
      - TomasSedovic 16y ago
        To my (limited) knowlegde: you can modify the packets, but since they're encrypted, you shouldn't be able to change the transmitted data to your liking. Unless you breach it somehow, you can only do denial-of-service, not a true man-in-the-middle.
        NateLawson 16y ago
        No, all encryption modes in SSL also use some kind of integrity protection (MAC, usually). So SSL gets you privacy in that the message you send is encrypted and authentication in that only the endpoint could have transmitted that exact message. You modify the packets of an SSL session and your data is discarded.

by ErrantX 16y ago

cortesi 16y ago

This is not correct, on a few fronts. It _is_ possible to secure data with just Javascript (with care), and "host proof" describes a design philosophy that has real meaning - Google the term, and look at excellent commercial projects like Clipperz (who use "zero knowledge" as a synonym for "host proof"). You can also read this post I wrote when I took my first skeptical look at the idea. It discusses how and why the host-proof idea could work, and finds some flaws in Clipperz and PassPack, the two most prominent "host-proof" commercial apps: http://corte.si/posts/security/hostproof.html http://corte.si/posts/security/hostproof.html I should note that Clipperz has now addressed all the points I raised in my post. The "host-proof" idea has been around for a while, but is really just in its infancy. There's a lot of work to be done, but the idea is both important and promising.

ErrantX 16y ago
Yes I understand your point; but it still comes down to trusting to server (which is fine, but it is something "host proof" doesn't really encourage IMO). The verification is all very well and good; but you have to either verify the code each time (a pain) or trust the server between the times you do review the code. For most people reviewing the code is impractical. We discussed all this before in great detail; I'll try to dig out the threads. But from a security perspective this sort of stuff has a use, but not for things you really must keep secure. As a start: because the code of the app is sent "over the wire" with some regularity it is trivial to intercept and modify it.
- cortesi 16y ago
  Again, you should read more on this issue before you criticize the idea in absolute terms. Yes, verification is necessary, which is why I wrote a browser addon that can do hash-based verification of the application every time the page is loaded (described here: http://corte.si/posts/security/crypsr.html http://corte.si/posts/security/crypsr.html, with links to the github project), and which is why cryp.sr has application hashes published with every modification. Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat. The techniques are still clunky - but that's because it's very early days, and we're still developing the tools and techniques to make things seamless. The basic idea, however, is entirely sound, and increasingly important.
  - gloob 16y ago
    Yes if you send your traffic unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and any other good host-proof app, uses SSL, which is designed to counter exactly that type of threat. I'll admit up-front that I have only a cursory knowledge of security topics, but it was my understanding that SSL prevents the traffic from being read, but not from being modified. Am I incorrect in this belief?
    - TomasSedovic 16y ago
      To my (limited) knowlegde: you can modify the packets, but since they're encrypted, you shouldn't be able to change the transmitted data to your liking. Unless you breach it somehow, you can only do denial-of-service, not a true man-in-the-middle.
      - NateLawson 16y ago
        No, all encryption modes in SSL also use some kind of integrity protection (MAC, usually). So SSL gets you privacy in that the message you send is encrypted and authentication in that only the endpoint could have transmitted that exact message. You modify the packets of an SSL session and your data is discarded.