4 ms·
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that o
by sarciszewski 12y ago
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that only executes signed code.
Not only do you need to obtain access to the server, you also need the private key of its operator. (Which should be kept offline for signing.) If they don't surrender the key, then you cannot compromise their visitors.
This can also be a mitigation for drive-by malware exploits and whatnot.
(I emailed this to LiberationTech last year, no one took any interest in the idea.)
- ultramancool 12y agoIt's an interesting idea, but currently quite impractical as there's no infrastructure for it. The most secure way right now is to isloate your Tor browsing activities to a virtual machine which is only able to access the internet via Tor. Create a VM to act as a middle node with 2 NICs, the first of which will connect to the internet and the second of which will connect to the other VM. Disable any unnecessary services, expose only Tor's proxy to the second NIC. Create the other VM with 1 NIC in the virtual network with the Second NIC on the other VM. This enforces Tor-only access for the second VM. Any activity must go over Tor or it may not access the internet. Snapshot the VMs. Always restore the snapshots when beginning a new session. Setting this up takes some time, but nearly guarantees an exploit cannot escape. I also recommend disabling unnecessary services which may expose the host to attack (ie: file sharing and video and mouse acceleration) through the second VM. It may be more secure to use a low-level emulation (QEmu, VirtualBox or VMWare with hardware acceleration disabled) rather than a hypervisor-based VM solution for this.
- deleted 12y ago[deleted]
- undefined0 12y ago> It's an interesting idea, but currently quite impractical as there's no infrastructure for it. If TOR and Namecoin hooked up, Namecoin could provide a list of page hashes for a given onion address. Better still, interrogate Namecoin's DNS system into TOR and then make Hidden Services accessible via human readable domain names.
- daveloyall 12y agoYou mean some people use Tor differently than as you suggest? Why? I had assumed that everyone would be either on the 'net with their 'net computer or on tor with their tor computer. Doing both with one computer obviously defeats the purpose, doesn't it? ...Also, the chances of breaking out of a VM into the host are non-zero. Just sayin'.
- eli 12y agoSo you're going to fork the web?
- sarciszewski 12y agoNo more than NoScript forks the web.
- eli 12y agoSo if I hack a website what's stopping me from serving javascript with no signature or my own signature?
- sarciszewski 12y agoAh, key management, the bane of any asymmetric crypto system! My draft specified TOFU; if a site was previously signed and no signature is attached, don't allow any JS. If the signature doesn't match the key cached in the browser, go full noscript.
- eli 12y agoWouldn't I typically want my Tor Browser to not record any details about sites I have previously visited? Seems like a lot of work for modestly more security.
- sarciszewski 12y agoDisclaimer: This was an idea that nobody ever showed interest in and therefore I never put forth the effort to refine and flesh out. Feel free to take it and run with it if you have better ideas.
- onedognight 12y agoThis was solved for the case of http/https with the "Strict-Transport-Security" header which says that all future communication (for a certain time) will always be over HTTPS. The browser could easily respond to similar "Strict-Signature-Security" header requiring all files to come with a Signature header in the future.
- teraflop 12y agoHow does the browser get the public key in order to verify the signature? And how is this any different from just serving scripts over HTTPS?
- icebraining 12y agoNot OP, but I think there's a big difference. HTTPS protects code in transit, but if you can hack the server, you can change the JS code. This proposal would cover that gap.
- sarciszewski 12y agoThat's exactly the issue. This is designed to work in conjunction with HTTPS/Tor such that if the server is compromised, unsigned JS payloads cannot compromise the user.
- wahern 12y agoYou could just make it an HTML meta tag which specifies trusted keys. And add an attribute to the script tag which contains the signature. Might need to disable inline JavaScript, though. And double-check that meta tags are only meaningful when located in their proper place in the head tag. I don't like the HTTP header idea, 'cause it precludes static content unless you modify the web server. And I don't like external files which are automatically read by the browser because then you run into namespace problems. Keeping everything in the HTML document provides tidy isolation.
- sarciszewski 12y agoIf you're pulling the public key from the document to use it to verify the document, you've already lost.
- wahern 12y agoYou're using it to verify JavaScript code, not the document. Presuming you also disabled inline JavaScript, you've just shutdown cross-site scripting (XSS) attacks.
- chatmasta 12y agoThat's a cool idea, but it comes with a lot of overhead. Javascript files are one of the most heavily-cached on the web, and by signing them with PGP, you cripple your caching ability. Or am I missing something?
- sarciszewski 12y agoThe original idea I had was to have an index (think hybrid cache.manifest and Content-Security-Policy header) of relative URLs and their SHA3 hashes, then that file was signed. If anything fails to validate, it doesn't run.
- Retric 12y agoSigning just prevents you from altering the files so you can cache them just fine.
- martindale 12y agoYou could also just sign the hash.
- dobbsbob 12y agoNone of the vendors have javascript enabled though, how to disable .js was in the vendor guide and all over their forums as a warning.
- sarciszewski 12y agoThis isn't just a "fight the man" anti-FBI idea, it's meant to stop the spread of drive-by malware on legitimate sites too. :)