Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Firefox supports proxy via unix domain socket and tor daemon supports unix sockets too, so you can setup torbrowser in a VM/container without any network access to add additional safety against leaks. The sole communication channel to the tor daemon via unix socket(s). For vm, use virtfs/9p to share between the daemon and browser, for container just bind mount it. To allow torbrowser to control the tor daemon, you can use socat as a proxy over an additional unix socket since tor's control port does not directly support using a unix socket.

The whonix project has good info on the environment variables you will need to set to get the torbrowser to play nice with an external tor daemon, so you do not need to resort to tor over tor which will make your traffic stand out.

https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/m...

IMO, torbrowser, on platforms that support it, should separate daemon and browser by default, with browser in a separate network namespace with no network interfaces.

But, if zero day in tordaemon, and your adversary is US gov't or other well resourced organization, it is probably still game over. Not to mention NSA scale traffic analysis that Schneier seems to be suggesting as a possibility here, which can only be defended against by only using Internet access that can never be tracked back to you. For downloading bookwares off libgen, the above mitigation is probably sufficient, though, if not a bit overkill.



> since tor's control port does not directly support using a unix socket

Note, this part is incorrect, the tor control port works over a unix socket natively. I just spent some quality time with the torrc manpage and am in the process of fixing my setup.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: