When ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport name
tcpdump -n host 184.108.40.206
Run tor with this torrc:
UseBridges 1 Bridge obfs4 220.127.116.11:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0
See a connection to 18.104.22.168: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:1
tor 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 legacy/trac#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
Bridge, but torrc-defaults contains
There was another ticket about tor occasionally connecting to PT bridges as if they were ordinary guards: legacy/trac#20532 (moved). It may be the same as this. At legacy/trac#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