Opened 4 months ago

Closed 6 weeks ago

#29876 closed defect (fixed)

get_proxy_type() may be wrong when unused PT configured

Reported by: catalyst Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: technical-debt, tor-pt, ex-sponsor-19
Cc: brade, mcs Actual Points:
Parent ID: #29670 Points:
Reviewer: Sponsor: Sponsor19-can

Description

Related to #28925, it looks like get_proxy_type() in connection.c only checks whether any client transport plugins are configured to determine whether a pluggable transport is in use. If ClientTransportPlugin is set, but no bridges are configured to use it, and a SOCKS proxy is also configured, maybe some code in connection.c could inappropriately attempt to do PT stuff when it should only be doing vanilla SOCKS proxy stuff?

It might turn out to be ok, but it's not immediately obvious.

Child Tickets

Change History (6)

comment:1 Changed 4 months ago by mcs

Cc: brade mcs added

I don't fully understand the issue here, but note that Tor Browser does ship with several pre-configured ClientTransportPlugin lines in our bundled torrc-defaults file.

comment:2 in reply to:  1 ; Changed 4 months ago by catalyst

Keywords: technical-debt added

Replying to mcs:

I don't fully understand the issue here,

Neither do I, which is why I filed this ticket. It might turn out to be not a problem in practice.

but note that Tor Browser does ship with several pre-configured ClientTransportPlugin lines in our bundled torrc-defaults file.

Thanks, that's good to know. So the torrc-defaults file (or at least the ClientTransportPlugin lines?) remains the same regardless of Tor configuration changes in Tor Browser's Network Settings?

I think that means get_proxy_type() always will return an incorrect PROXY_PLUGGABLE for Tor Browser, but the behavior might be functional anyway. I (or someone else) would likely have to look more closely at the code consuming get_proxy_type() to be sure. Even if the behavior is functionally correct, this might be some technical debt that we should eliminate.

comment:3 in reply to:  2 Changed 4 months ago by mcs

Replying to catalyst:

Thanks, that's good to know. So the torrc-defaults file (or at least the ClientTransportPlugin lines?) remains the same regardless of Tor configuration changes in Tor Browser's Network Settings?

Yes. Tor Launcher adds/removes UseBridges=1 and various Bridges lines via the control port, but the ClientTransportPlugin lines all come from torrc-defaults. That file is never modified unless a user edits it (which they should not do; in Tor Browser, we ask them to edit torrc only).

comment:4 Changed 6 weeks ago by catalyst

Parent ID: #29670

This looks like the cause of #29670.

comment:5 Changed 6 weeks 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:6 Changed 6 weeks ago by catalyst

Resolution: fixed
Status: newclosed

Code is in parent ticket, which is merged and pending backport.

Note: See TracTickets for help on using tickets.