5 ms·

I think a lot of this has been covered elsewhere before: - when using tor you should disable javascript because a malicious or compromised site can use javascr

I think a lot of this has been covered elsewhere before: - when using tor you should disable javascript because a malicious or compromised site can use javascript to do non-tor stuff that potentially compromises your location. (can be a big pill to swallow, web without javacript is very 90s) - Run torbrowser within a secure VM or separate device using Tails to minimize your activity footprint - Use a VPN when connecting to TOR (I also put my TOR services behind their own VPN so even if the entry point is known you can't get the origin IP from it) - As an added protection I use firewall rules to ensure that only the tor client process can communicate out, any other attempt to send or receive traffic to the public internet gets dropped.

sillystuff 4y ago
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/master/usr/libexec/anon-ws-disable-stacked-tor/torbrowser.sh 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.
- sillystuff 4y ago
  > 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.
Seattle3503 4y ago
> - Use a VPN when connecting to TOR (I also put my TOR services behind their own VPN so even if the entry point is known you can't get the origin IP from it) Has this advice been studied? If everyone uses a VPN you could be reducing network diversity. A single compromised provider could make correlation attacks easier across the entire network. I'm not saying that's certain, but I'm generally skeptical of "hone remedies" when it comes to Tor. There is so much potential for counterintuitive interaction.
- rz2k 4y ago
  … ROT13 is known to be a very insecure method of encryption, therefore you should run it twice on your messages to keep adversaries from reading your secrets. Unless you’re completely certain it’s impossible for the VPN providers to coordinate, that sounds like a way to short circuit the entire tor infrastructure.
  - zxcvbn4038 4y ago
    And the Oscar goes to rz2k for saying that with a straight face ;)
mik1998 4y ago
> Use a VPN when connecting to TOR You should not do this. It is at best useless, at worst strictly negative. A VPN tunnels all your traffic through their own servers, so they are a single point of failure roughly equivalent to your ISP. Anyone with access to the VPN servers could spy on all of your traffic, completely bypassing Tor. If you pay for the VPN with a credit card, you can be easily identified.
- notfed 4y ago
  > Anyone with access to the VPN servers could spy on all of your traffic, completely bypassing Tor. Hmm, can you explain how this could possibly be true? I think the VPN couldn't see any more than your ISP could have.
  - hashstring 4y ago
    The situation is different, think about nodes and encrypted channels between them. If you encrypt traffic on your host properly and send it off to a remote host, your ISP (node(s) in between) sees encrypted traffic. If you create an encrypted VPN connection to a VPN providers server and then configure a second encrypted connection (e.g. through Tor) from that VPN providers server to a remote host, then your VPN provider is able to see exactly what happened on that VPN providers server; since that’s where the encryption (and decryption) happens.
    - robjan 4y ago
      The Tor tunnel will go through the VPN tunnel and terminate on your device, not at the VPN provider.
- sasas 4y ago
  It's not a good idea, but not for the reason stated here. The TOR client will establish a tunnel OVER the VPN to the entry node, so the VPN provider will only see this encrypted traffic. The VPN server cannot spy on you. When you connect to TOR it carefully selects your circuit for diversity over the Internet between each hop (for example avoiding your entry and exit nodes not being on the same service provider). By using a VPN your opening the possibility for something to go wrong here.
jesprenj 4y ago
Is bandwidth profiling not used? Can't an agency on the scale of FBI, provided they can control the website contents or at least see the access logs, determine from passive observing of end user connections, who downloaded the website?
noodleman 4y ago
Why would you put TOR behind a VPN? That just increases the surface area for attack.
- TechBro8615 4y ago
  It does add another entity who can identify you (your VPN provider), but it doesn't strictly increase the surface area, since it avoids passive surveillance tripwires at your ISP looking for "interesting" traffic like active connections to Tor nodes. Now, if your ISP is monitoring Tor connections, they're probably monitoring VPN connections too. But at this point VPN services like Apple Private Relay are so commonplace that it's not too unusual to route all your traffic through a WireGuard endpoint. So the burden of surveillance shifts to your VPN provider, who may be worse or better than your ISP in terms of keeping logs, respecting privacy and responding to subpoenas. Note that "VPN provider" could refer to any entity who is next in the connection chain after your ISP. That could be some public VPN providers like Cloudflare or Apple Private Relay (which is run by Cloudflare and Akamai). Or, if you host your own VPN, it could be your VPS provider. If your goal is to blend in, you probably want to use the public VPN provider where exit IP addresses are (theoretically) shared between a (limited) number of users at any given time. Whereas a VPN on your own box will have an exit IP that is uniquely attributable to you, making you not only easier to trace, but also easier to hack, through any vulnerabilities you might have introduced when setting up the server.

sillystuff 4y ago

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/master/usr/libexec/anon-ws-disable-stacked-tor/torbrowser.sh 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.

sillystuff 4y ago
> 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.

Seattle3503 4y ago

> - Use a VPN when connecting to TOR (I also put my TOR services behind their own VPN so even if the entry point is known you can't get the origin IP from it) Has this advice been studied? If everyone uses a VPN you could be reducing network diversity. A single compromised provider could make correlation attacks easier across the entire network. I'm not saying that's certain, but I'm generally skeptical of "hone remedies" when it comes to Tor. There is so much potential for counterintuitive interaction.

rz2k 4y ago
… ROT13 is known to be a very insecure method of encryption, therefore you should run it twice on your messages to keep adversaries from reading your secrets. Unless you’re completely certain it’s impossible for the VPN providers to coordinate, that sounds like a way to short circuit the entire tor infrastructure.
- zxcvbn4038 4y ago
  And the Oscar goes to rz2k for saying that with a straight face ;)

mik1998 4y ago

> Use a VPN when connecting to TOR You should not do this. It is at best useless, at worst strictly negative. A VPN tunnels all your traffic through their own servers, so they are a single point of failure roughly equivalent to your ISP. Anyone with access to the VPN servers could spy on all of your traffic, completely bypassing Tor. If you pay for the VPN with a credit card, you can be easily identified.

notfed 4y ago
> Anyone with access to the VPN servers could spy on all of your traffic, completely bypassing Tor. Hmm, can you explain how this could possibly be true? I think the VPN couldn't see any more than your ISP could have.
- hashstring 4y ago
  The situation is different, think about nodes and encrypted channels between them. If you encrypt traffic on your host properly and send it off to a remote host, your ISP (node(s) in between) sees encrypted traffic. If you create an encrypted VPN connection to a VPN providers server and then configure a second encrypted connection (e.g. through Tor) from that VPN providers server to a remote host, then your VPN provider is able to see exactly what happened on that VPN providers server; since that’s where the encryption (and decryption) happens.
  - robjan 4y ago
    The Tor tunnel will go through the VPN tunnel and terminate on your device, not at the VPN provider.
sasas 4y ago
It's not a good idea, but not for the reason stated here. The TOR client will establish a tunnel OVER the VPN to the entry node, so the VPN provider will only see this encrypted traffic. The VPN server cannot spy on you. When you connect to TOR it carefully selects your circuit for diversity over the Internet between each hop (for example avoiding your entry and exit nodes not being on the same service provider). By using a VPN your opening the possibility for something to go wrong here.

jesprenj 4y ago

Is bandwidth profiling not used? Can't an agency on the scale of FBI, provided they can control the website contents or at least see the access logs, determine from passive observing of end user connections, who downloaded the website?

noodleman 4y ago

Why would you put TOR behind a VPN? That just increases the surface area for attack.

TechBro8615 4y ago
It does add another entity who can identify you (your VPN provider), but it doesn't strictly increase the surface area, since it avoids passive surveillance tripwires at your ISP looking for "interesting" traffic like active connections to Tor nodes. Now, if your ISP is monitoring Tor connections, they're probably monitoring VPN connections too. But at this point VPN services like Apple Private Relay are so commonplace that it's not too unusual to route all your traffic through a WireGuard endpoint. So the burden of surveillance shifts to your VPN provider, who may be worse or better than your ISP in terms of keeping logs, respecting privacy and responding to subpoenas. Note that "VPN provider" could refer to any entity who is next in the connection chain after your ISP. That could be some public VPN providers like Cloudflare or Apple Private Relay (which is run by Cloudflare and Akamai). Or, if you host your own VPN, it could be your VPS provider. If your goal is to blend in, you probably want to use the public VPN provider where exit IP addresses are (theoretically) shared between a (limited) number of users at any given time. Whereas a VPN on your own box will have an exit IP that is uniquely attributable to you, making you not only easier to trace, but also easier to hack, through any vulnerabilities you might have introduced when setting up the server.