[tbb-bugs] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
-------------------------------------------------+-------------------------
 Reporter:  ggus                                 |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-circuit-display,                 |  Actual Points:  0.25
  TorBrowserTeam201910R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by pospeselr):

 * status:  needs_information => needs_review
 * cc: tbb-team (added)
 * keywords:  tbb-circuit-display => tbb-circuit-display,
     TorBrowserTeam201910R
 * actualpoints:   => 0.25


Comment:

 Here's a patch that fixes this issue:

 tor-button:
 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_32125&id=56a68b45decbbbf5e6e064f5bd23a21d622e81d0

 With this patch, bridges which have no provided fingerprint will display
 simply as "Bridge" rather than "Bridge: obfs4 127.0.0.1" (for example).
 Without a fingerprint, neither type nor ip are determinable from tor-
 button.

 ----


 I've dug into this issue a bit and here's a summary of the problem.

 Tor Browser builds the circuit display by requesting the circuit (as a
 list of ids/fingerprints) for the current first-party domain. Then, Tor
 Browser checks to see if each of nodes are a Bridge by requesting the
 bridge strings via {{{getconf bridge}}}. Next, we look for the current id
 in each of the bridge objects and execute some UI logic that displays each
 node's info (whether bridge or vanilla relay).

 When the user provides a bridge without a fingerprint we run into a few
 problems resulting in the broken behavior in the bug. First of all,
 requesting the bridge list via getconf bridge (basically) just returns the
 bridge strings stored in torrc. These strings are either provided by the
 user, brigedb, or our builtin bridge preferences. The bridge string format
 is something like {{{$type $ip:$port $optionalfingerprint
 $otherstuff...}}}.

 As the fingerprint is optional, the bridge parser in tor-control-port.js
 ends up storing the $otherstuff data as the id/fingerprint.

 Then, getBridge() in tor-circuit-display.js fails to find a bridge by
 id/fingerprint (because our bridge has $otherstuff in the id field) and
 returns null.

 Next, nodeDataForId() in tor-circuit-display.js skips over the 'bridge'
 section (as the result of getBridge() is null) and it assumes we are
 dealing with a relay. The failing {{{GETINFO ns/id/$fingerprint}}} call
 ends up throwing exception because we're passing in a bridge
 id/fingerprint which is not part of the consensus (according to arma). As
 a result, the IP of the relay is never set.

 Since the IP of the relay is not stored, updateCircuitDisplay() in tor-
 circuit-display() (which is responsible for creating the visuals including
 the New Circuit button) throws after trying to dereference a null
 reference, resulting in the behavior described in the description.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32125#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online