If I supplied 3 bridges to /etc/tor/torrc, how are they being chosen? In random or first line first?
If the chosen bridges, somehow, doesn’t work (rejecting or broken). Will there be risk of leak? And what will happen - packet is dropped or Tor will choose a new one from the list and continue without dropping (no need to resend).
Is it recommended to put as many bridges as possible in /etc/tor/torrc?
Is it recommended to change list of bridges often?
If using bridges “makes things harder for your ISP to know that you’re using Tor”, then everyone should be using bridges whenever possible? If not, are bridges more vulnerable to attacks compared with entry guards?
Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards.Source: bridge vs non-bridge users anonymity.
I’ve managed to add bridges to standalone Tor browser and it works in a censored/restricted environment. However, I’ve tried mod’ing /etc/tor/torrc file per instructions for Whonix 12 - no luck. Here is excerpt of my torrc re: bridges:…
I’m running Whonix 12. The bridges were freshly obtained/added. I’ve tried reloading TOR and also tried restarting the Gateway. Have also tried regular bridges and other forms of bridges - none work, same results every which way. Note image below - ARM shows no message traffic.
Did you change any networking related settings? Don’t change stuff that is not in documentation. (If you did undo and if you don’t know how then reinstall Whonix.)
Check /var/run/tor/log for any useful messages.
kdesudo kwrite /var/run/tor/log
Any messages about the clock or other hints there?
(Some of these messages are non-issues: Tor - Whonix)
I’m running Whonix 12 via Virtualbox Version 5.0.10 r104061 on Windows 10.
re: network settings - no I didn’t make any changes
re: /usr/share/tor/tor-service-defaults-torrc - no changes
re: /var/run/tor/log - I config’d torrc w/ new bridges and rebooted Gateway
Jan 20 12:42:48.000 [notice] Delaying directory fetches: No running bridges
Jan 20 12:42:48.000 [notice] Signaled readiness to systemd
Jan 20 12:42:50.000 [notice] Bootstrapped 5%: Connecting to directory server
Jan 20 12:42:50.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jan 20 12:42:51.000 [warn] Proxy Client: unable to connect to 172.245.230.92:42061 ("server rejected connection")
Jan 20 12:42:51.000 [warn] Proxy Client: unable to connect to 94.242.249.8:33842 ("server rejected connection")
re:user@host:/var/log$ tail -f sdwdate.log
1351: sdwdate (not timesync!): signal SIGTERM received...
1351: sdwdate (not timesync!): signal SIGTERM received. Cleaning up...
1351: sdwdate (not timesync!): signal SIGTERM received. Exiting.
1338: Running sdwdate... pid: 1338 | LD_PRELOAD:
1338: sdwdate_preparation: who_ami is set to user.
1338: dispatching DISPATCH_PRE (SDW_MODE: startup): /usr/lib/timesync/timesync_pre --autostart --identifier "timesync" --progressbaridx "$ID" --mode "$SDW_MODE" --whoami "$who_ami"
1338: dispatching DISPATCH_PRE done.
1338: SDWDATE_CURRENT_POOL: SDWDATE_POOL_ONE | array_length: 14 | allowed_member_failures: 5 | temp: 4.76 | array_length_remember: 0
1338: dispatching DISPATCH_PREREQUISITE (SDW_MODE: startup) (LD_PRELOAD: ): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
1338: DISPATCH_PREREQUISITE exited 2 | Tor is not yet fully bootstrapped. 10 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server" | waiting...
Meanwhile… I have reinstalled Gateway 12 VM from ~.ova. Using identical bridge setup I get same problems when I try to connect in restricted environment [behind workplace firewall] whereas there are no problems connecting Gateway to TOR network using same bridges when I’m in an unrestricted/public environment.
Thanks! It’s good to understand these reports so we can document this better.
sdwdate log looks like expected in such a situation, no issue there.
Your description indicates that this issue is not caused by Whonix but by the workplace firewall. I speculate, that they likely block these outgoing ports that your bridge is using for any connection. Try using some [private] [obfuscated] bridges on port 80 or 443.
(
In case you don’t know already, or for other readers, this is what is defined as IP / port in this context. Example:
172.245.230.92:42061
IP:PORT
IP would be 172.245.230.92. Port would be 42061.
)
(Less likely, I speculate, that they detect and block Tor bridge traffic.)
Or if you do not try to hide being a Tor user, you could try not using bridges. Use the public Tor network. And the following setting in /etc/tor/torrc, which will limit Tor’s outgoing ports to 80 and 443.
