Opened 15 months ago

Last modified 11 days 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:

Description

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=0

See 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: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 #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 (7)

comment:1 Changed 15 months ago by nickm

Keywords: 034-roadmap-proposed added

comment:2 Changed 10 months ago by nickm

Milestone: Tor: 0.3.6.x-final

comment:3 Changed 7 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 5 months ago by nickm

Sponsor: Sponsor19-can

comment:5 Changed 5 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 days 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 11 days 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.

Note: See TracTickets for help on using tickets.