41–50 of 91 posts
EDIT: to spell this out, you would, self host the stanford library, for example, and have this service verify it against a known good checksum.
What do you guys think about a service (think pingdom) that you set up to periodically request a js file from your server and check it against a known good checksum? EDIT: to spell this out, you would, self host the stanford library, for example, and have this service verify it against a known good checksum.
Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…
Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…
Perhaps the key to crypto in the browser would be to implement it in extensions rather than on webpages? Extensions run in a higher level of security clearance, are sandboxed from the rest of the page, and are much more intolerant of code injection.
browsers are being patched for a long time now.. to fit into sophisticated models.. it came all over here, by using duct tape.. but now it can be patched anymore to get into the next level.. it cant reach the next level because its broken by design.
how long until people face the reality?
Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…
Earlier quoted context omitted.
You must always trust something . In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a…
The point anon1385 is trying to make about JavaScript clients is that they can be changed at any time by the web service provider, where as open source clients can be 'verified' once by the open source community and then can't be easily changed by the service provider (unless they have an auto updater, which Tarsnap does not)
Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…
If you don't trust the server, you're screwed anyway.
Earlier quoted context omitted.
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).
Suppose we sign 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:
sjcl = ...
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.