4 ms·

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

by 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.
  - NateLawson 16y ago
    I think you should say "unproven" instead of "clunky". I don't know any paper that has been published on how to unambiguously verify JS content from a browser plugin. I took a quick look at your code for this. I think you'd be more honest to say that the security of your plugin rests on the inability for an attacker to evade your regex. In particular, the functions apphash_hostile_check() and apphash_split() could leave a route for attackers to smuggle in hostile data without changing the hash. This comment is troubling: // Do we need to check all frames // What happens if tab loads in background? Do we need to run this when tabs switch? Also, using a hash instead of an HMAC leaves you open to length extension attacks. More importantly: why leave a potential door open by taking on the hard MitM problem of parsing and hashing JS from your browser plugin in a way that is unambiguous with how the browser will render it? Instead, ship the encryption code in the plugin itself. Now a user who has downloaded a correct plugin one time has assurance that it won't be swapped out from under themselves for a trojan. However, I'm guessing that would violate your actual business model which divides users' trust into two categories: unaware and unwarranted. The unaware will happily trust your claims of "host-proof security" and not use the plugin. The more technically informed will have unwarranted trust that the browser plugin is difficult to evade. I expect that the latter problem is the "software obfuscation problem" combined with the "vantage point problem". That's not something you want to make your lynchpin of assurance. I hope this convinces you to drop the misnomer of "host-proof security".

by cortesi 16y ago

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.
- NateLawson 16y ago
  I think you should say "unproven" instead of "clunky". I don't know any paper that has been published on how to unambiguously verify JS content from a browser plugin. I took a quick look at your code for this. I think you'd be more honest to say that the security of your plugin rests on the inability for an attacker to evade your regex. In particular, the functions apphash_hostile_check() and apphash_split() could leave a route for attackers to smuggle in hostile data without changing the hash. This comment is troubling: // Do we need to check all frames // What happens if tab loads in background? Do we need to run this when tabs switch? Also, using a hash instead of an HMAC leaves you open to length extension attacks. More importantly: why leave a potential door open by taking on the hard MitM problem of parsing and hashing JS from your browser plugin in a way that is unambiguous with how the browser will render it? Instead, ship the encryption code in the plugin itself. Now a user who has downloaded a correct plugin one time has assurance that it won't be swapped out from under themselves for a trojan. However, I'm guessing that would violate your actual business model which divides users' trust into two categories: unaware and unwarranted. The unaware will happily trust your claims of "host-proof security" and not use the plugin. The more technically informed will have unwarranted trust that the browser plugin is difficult to evade. I expect that the latter problem is the "software obfuscation problem" combined with the "vantage point problem". That's not something you want to make your lynchpin of assurance. I hope this convinces you to drop the misnomer of "host-proof security".