4 ms·

If you don't trust the server, you're screwed anyway.

by sdevlin 13y ago

jonpaul 13y ago
Maybe, maybe not. But if you only rely upon the client-side feature of the app and if code signing is employed, you could safely use the app without fear of potentially your private data being stolen (assuming the original code doesn't send private data to the server).
- sdevlin 13y ago
  Well, let me explain my thinking. Suppose we sign https://server.com/sjcl.js https://server.com/sjcl.js. That resource is now tamper-proof in the event that server.com is compromised. But what about the rest of the application HTML/js? For example, an attacker could just say: <script src="/sjcl.js"></script> <script>sjcl = ...</script> And overwrite the library on the client side. Ok, suppose the browser support for content-signing prevents this somehow. The attacker can still modify the application-level code to use the library unsafely. I'm not totally familiar with the API sjcl exposes, but consider something like the e=1 RSA bug that was found recently. Even if sjcl's API is so great that it's impossible to misuse, an attacker could simply render application code that doesn't use it at all. Or he could just log keystrokes and phone home the pre-encryption content. What if we sign everything, including application HTML/js? Now we have another problem. We've basically resigned ourselves to serving only static content. We can't render any user input, because this would require a new signature. Probably not a useful web app.
  - methehack 13y ago
    A single page web app might be statically delivered and useful... Further, I think it just means that the page that does the crypt/decrypt has to be statically delivered, not the whole app. EDIT: so..if you had a single page web app, signed or even checksum'd the whole hunk in a known good state, couldn't you then trust the execution of the app? Further if you had an external service (as I propose in a comment below) that validated the signature/checksum couldn't you then trust the whole package?
tghw 13y ago
Consider CDNs and static content domains. It's generally easier to break or MITM a CDN or static content server without people noticing. This way, you could trust that the code you received was what you were expecting.

If you don't trust the server, you're screwed anyway.

by sdevlin 13y ago

If you don't trust the server, you're screwed anyway.

Maybe, maybe not. But if you only rely upon the client-side feature of the app and if code signing is employed, you could safely use the app without fear of potentially your private data being stolen (assuming the original code doesn't send private data to the server).

sdevlin 13y ago
Well, let me explain my thinking. Suppose we sign https://server.com/sjcl.js https://server.com/sjcl.js. That resource is now tamper-proof in the event that server.com is compromised. But what about the rest of the application HTML/js? For example, an attacker could just say: <script src="/sjcl.js"></script> <script>sjcl = ...</script> And overwrite the library on the client side. Ok, suppose the browser support for content-signing prevents this somehow. The attacker can still modify the application-level code to use the library unsafely. I'm not totally familiar with the API sjcl exposes, but consider something like the e=1 RSA bug that was found recently. Even if sjcl's API is so great that it's impossible to misuse, an attacker could simply render application code that doesn't use it at all. Or he could just log keystrokes and phone home the pre-encryption content. What if we sign everything, including application HTML/js? Now we have another problem. We've basically resigned ourselves to serving only static content. We can't render any user input, because this would require a new signature. Probably not a useful web app.
- methehack 13y ago
  A single page web app might be statically delivered and useful... Further, I think it just means that the page that does the crypt/decrypt has to be statically delivered, not the whole app. EDIT: so..if you had a single page web app, signed or even checksum'd the whole hunk in a known good state, couldn't you then trust the execution of the app? Further if you had an external service (as I propose in a comment below) that validated the signature/checksum couldn't you then trust the whole package?

tghw 13y ago

Consider CDNs and static content domains. It's generally easier to break or MITM a CDN or static content server without people noticing. This way, you could trust that the code you received was what you were expecting.