Opened 2 years ago

Last modified 9 months ago

#25528 new defect

When ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport name

Reported by: dcf Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: pt, bootstrap, bridge-client, bridge-bypass, 034-roadmap-proposed, 041-proposed, ex-sponsor-19, ex-sponsor19
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor30-can


Start tcpdump -n host

Run tor with this torrc:

UseBridges 1
Bridge obfs4 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0

See a connection to, 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

tor actually tries to connect to the 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

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 and, which are the two versions I tested.

I found this problem through a user report at #25527. 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. It may be the same as this. At #25527 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.

Child Tickets

Change History (9)

comment:1 Changed 2 years ago by nickm

Keywords: 034-roadmap-proposed added

comment:2 Changed 22 months ago by nickm

Milestone: Tor: 0.3.6.x-final

comment:3 Changed 19 months ago by nickm

Milestone: Tor: 0.3.6.x-finalTor: 0.4.0.x-final

Tor 0.3.6.x has been renamed to 0.4.0.x.

comment:4 Changed 17 months ago by nickm

Sponsor: Sponsor19-can

comment:5 Changed 17 months ago by nickm

Keywords: 041-proposed added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Mark some 0.4.0.x tickets as proposed for 0.4.1.x

comment:6 Changed 12 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:7 Changed 12 months ago by gaba

Keywords: ex-sponsor19 added
Sponsor: Sponsor19-can

Remove sponsor 19 and add a keyword ex-sponsor19 to mark all the tickets that could have been in the scope of the sponsor.

comment:8 Changed 12 months ago by gaba

Sponsor: Sponsor30-can

There was a duplicate in #30875

Last edited 9 months ago by arma (previous) (diff)

comment:9 Changed 9 months ago by arma

This issue remains a pretty big usability gotcha -- I periodically run into users who have tried to configure obfs4 bridges and their Tor is trying to reach the obfs4 bridge like it's a vanilla bridge because they left out the extra magic line.

Note: See TracTickets for help on using tickets.