Hacker News Reader

Comment by sarciszewski | Hacker News Reader

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.)

View on HN

It'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.

> 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.

You 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'.

That'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?

The 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.

Signing just prevents you from altering the files so you can cache them just fine.

You could also just sign the hash.

How 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?

Not 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.

That'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.

You 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.

If you're pulling the public key from the document to use it to verify the document, you've already lost.

You'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.

None of the vendors have javascript enabled though, how to disable .js was in the vendor guide and all over their forums as a warning.

This 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. :)

So you're going to fork the web?

No more than NoScript forks the web.

So if I hack a website what's stopping me from serving javascript with no signature or my own signature?

Ah, 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.

Wouldn'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.

Disclaimer: 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.

This 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.

Reply on news.ycombinator.com