When ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport name
Start tcpdump -n host 83.212.101.3
Run tor with this torrc:
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0See a connection to 83.212.101.3:50002, despite that, lacking a ClientTransportPlugin line, tor doesn't know how to connect to an "obfs4" bridge.
Another way to see it is with this torrc, using a phony address like meek and snowflake do:
UseBridges 1
Bridge dummy 0.0.3.0:1tor actually tries to connect to the 0.0.3.0:1 address, and fails with an "Invalid argument" error:
[warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Invalid argument; RESOURCELIMIT; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.3.0:1)I expected instead that tor would not try to connect to the address, but rather would show this error message:
We were supposed to connect to bridge 'X' using pluggable transport 'Y', but we can't find a pluggable transport proxy supporting 'Y'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
The problem exists in both 0.2.9.14 and 0.3.4.0-alpha-dev, which are the two versions I tested.
I found this problem through a user report at #25527 (moved). The user was trying to run the Tor Browser tor, but they were in the wrong directory, so they were only getting torrc and not torrc-defaults. torrc contains UseBridges and Bridge, but torrc-defaults contains ClientTransportPlugin.
There was another ticket about tor occasionally connecting to PT bridges as if they were ordinary guards: #20532 (moved). It may be the same as this. At #25527 (moved) I speculated that the problem might have been caused by cached Guard entries, but that doesn't seem to be the case. All you have to do is omit the ClientTransportPlugin line.