3 ms·

Is it really impossible to make browser crypto a reality? Browser crypto can be scary! Do you have a malicious extension installed? We can't tell. Further, how

• kzahel 13y ago
  That sounds like an interesting use case, to have a browser API whereby an extension can disable other extensions from having access to certain domains. Perhaps you should submit a proposal and/or start a discussion on the appropriate mailing lists or bug trackers.
• IgorPartola 13y ago
  So even if you have a valid crypto implementation baked directly into the browser, and you can call crypto primitives directly from JavaScript, what's the point? I'd just grab whatever you are trying to encrypt before it gets encrypted, or decrypt it myself. Or replace the encryption functions with my own wrappers. Remember, I can introduce any code I want so long as I control the server which is serving your web page. JavaScript crypto is an attempt to not trust the server serving the data, but if that server, or any other server can inject any code into the web page which is handling the encrypted data, then you have no security. You are still left trusting the server to not screw you. Which is the same as using HTTPS which we already have today.
  • read 13y ago
    The point is to make it impossible to do what you just described. For example, to make it impossible for code sent by a server to execute any Javascript (or other scripting languages) at all. The server could instead send a data structure (as opposed to code) describing what to do, without having the power to replace any encryption functions or to execute additional functions that can subvert encryption. I realize a first version of this might sound too restrictive, but the point here is to show how it can be made to work. If it's possible to reduce what the server sent to the browser down to a fingerprint, it will also be possible for the browser extension to verify this fingerprint with multiple third parties. It can verify the fingerprint of the server code matches a fingerprint published on Twitter, or GitHub or other sources, which is something Keybase tries to do. An attacker would need to break into all (or at least a majority) of those services to serve you bad code. Which is harder than breaking only into your server. Forbidding other malicious browser extensions from interfering with a Keybase browser extension would allow the Keybase extension to perform all this fingerprint-checking logic with the guarantee the verification hasn't been tampered with.
    • IgorPartola 13y ago
      I don't get it. We can already do this: just have your server serve up XML, JSON, CSV, etc. Serving raw data with no code attached to it and disabling all extensions is something we already have. It's also not very useful. The point of web applications is that you can quickly distribute an application that runs on a common platform to everyone at once. It's a very nice idea. It is also insecure to boot. You are proposing two different changes. First, an enhanced ability of your web server to tell my browser which code is allowed and which code is not. This is good. This way, for example, my bank running on bank.example.com can tell my browser to not load any JavaScript code, or even any external resource from anywhere but bank.example.com. Now nobody can inject a JS file from evil.example.com. Fine-grained control over what the browser should and should not allow is a good thing. Controlling extensions is a bit different. I want my extensions to work. I want my ad blocker and my privacy guard to function even on sites like my bank's. In general, I would not want a site like Google to disable my ad blocker, that would be evil. Now, if you are saying that you want to sign this application and distribute the signature to other services so that I as the user can verify that the application blob I got from your server has not been tempered with, then how do you go about updating your application? If you found a critical bug in your JavaScript code and fixed it, now you have to create a new application blob, a new signature, and distribute that signature to all these other services that are supposed to arbitrate whether you are delivering honest code. Notice that you and you alone still control the signatures. There is no external verification that you are not delivering evil code to me, I still have to trust you, personally. Adding a signature/checksum means that the code you delivered has not been tempered by a third party, but it says nothing about you. And the point of in-browser crypto is so that I don't have to trust you. That's where the whole thing breaks down. If someone forces you to change your code, then update all the signatures and launch this code, then I still have no idea that it happened. So at best this might protect me from a malicious third party. But guess what? HTTPS already does that, and is a much simpler and proven solution. In-browser crypto does not work, and will never work. There is no way to make it work. The web is not a platform where the client can treat the server as untrusted. Every time I see an attempt at this I cringe since someone clearly wasted a whole lot of effort thinking they finally cracked it. Keybase is probably the first place where I am not completely against it as they are using it as a demo of what your actual client would be doing. Then again, they could probably have just scrapped it completely and done the whole thing server-side without so much effort. The alternative to what you are trying to achieve is this: every website is distributed as an open source application blob and a number of trusted third parties reviews the code before it gets published. These third parties each sign the the code with their private keys, showing that the believe the code to not be evil. The problem with this is that it completely undermines the central promise of the web application: instant deployment to all your users. This system is exactly what you have with Linux distributions' repositories. It work, it's secure, but it's slow.