3 ms·
You can have a signing committee vet the asset files and publish the signatures, which the browser extension looks for. It allows an upgrade path without having
by jaekwon 13y ago
You can have a signing committee vet the asset files and publish the signatures, which the browser extension looks for. It allows an upgrade path without having to go through the browser app store. For example, browser extensions installed using the Chrome app store updates automatically, which implies trust in Google.
The browser extension would only load vetted assets onto the DOM. In other words, you visit the site by opening a new tab and clicking on the extension. It then loads assets and checks that all the assets are signed by a trusted list of code-vetting signers. If all the signatures look good, then it loads the assets onto the DOM. This is no less secure than having all the client code in the extension.
- tptacek 13y agoYou can't just verify the static asset files, because that's not all the browser looks at when it builds up the Javascript runtime state.
- utnick 13y agoWhat else does it look at? I don't see what else would affect it besides things that you could also verify in theory.
- tptacek 13y agoWhy don't you start building out the answer to that question yourself?
- jaekwon 13y agoYour comment makes absolute sense if the extension is attempting to validate asset files after they'v been loaded. But the extension can be coded to only load vetted code. So I'm not sure what you're talking about. Please enlighten us.
- tptacek 13y agoIf the entire system lives in a browser extension, you're doing what I said in the comment at the top of this thread --- and why would you bother "loading" anything from the server at all? If you know the hash, you know what the file is supposed to be. Otherwise, almost every rendezvous you have with the server is an opportunity for methods to be rebound and your cryptosystem to be subverted. If you don't see how, it's a good exercise to investigate.
- MichaelGG 13y agoHe wouldn't know the hash beforehand, he'd know the keys that are supposed to sign assets. It would work if the plugin can inspect all browser requests attempt and verify every single asset before it's loaded into the browser.
- jahewson 13y agoA hostile browser extension which has permission to access all pages could inject its own code at runtime.
- jahewson 13y agoOr just have the signing committee publish signed JS code. There's no real difference between that and publishing a signed hash. Unfortunately other hostile extensions are still free to mess with the DOM, so it's all a bit pointless.
- jaekwon 13y agoA secure environment would require a vetted browser and no other hostile extensions. That's certainly possible, so Scramble does have a use.
- tptacek 13y agoI see. So, if I set up an intricate browser clean-room environment, and I assume that the Javascript verification system you come up with actually works, I can get some of the benefit of simply installing GPG and using POP mail.
- jaekwon 13y agoYou'd still have to vet your GPG install & mail client code. Also, it's not difficult to fork the code to create a client that doesn't use the browser at all. It just hasn't happened yet. How do you know which public key belongs to the address? Key servers? Web-of-trust? Look it up on their homepage? Scramble has an address -> pubkey resolution system which balances security with usability. At least with Scramble you can create a secure USB stick to boot from with all of that preconfigured. Any solution that uses bare GPG still has severe usability problems. http://www.gaudior.net/alma/johnny.pdf http://www.gaudior.net/alma/johnny.pdf
- blahbl4hblahtoo 13y agoVerifying the code on your system is something that can be easily done and easily verified the next time you use it. Its your system after all. I salute what you are trying to do, but you have to understand that the Js browser method, as it stands today, is a dead end.