[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #32204 [Core Tor/Tor]: Create either a query or event-based API to allow controllers (particularly Tor Browser) to reliably get circuit information



#32204: Create either a query or event-based API to allow controllers (particularly
Tor Browser) to reliably get circuit information
------------------------------+--------------------
     Reporter:  pospeselr     |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:  #31279
       Points:                |   Reviewer:
      Sponsor:  Sponsor30     |
------------------------------+--------------------
 Currently we can not get the address or type of a bridge by id/fingerprint
 if the bridge entry in torrc does not have the fingerprint string
 provided. This info is needed for the circuit display in Tor Browser,
 which currently just displays 'Bridge' without the address or type
 information.

 Tor Browser currently gets the circuit display information by first
 requesting the circuit for a given first-party domain/nonce pair. This
 returns an array of fingerprints. We then get the list of bridges stored
 in the torrc file via  {{{GETCONF bridge}}}. We compare each bridge's id
 to each node in the circuit. If a match if sound we know the node is a
 bridge and we display its information. Otherwise, we assume it is a relay
 and we query the information from tor via {{{GETINFO
 ns/id/$fingerprint}}}.

 With the change in #32125 we now infer that if the GETINFO call fails,
 it's because the id we've received is actually a Bridge whose info we do
 not know.

 Some possible options:

  - Tor updates the torrc with the Bridge's fingerprint once it is known.
 Tor Browser's logic doesn't change but there will be a window when a user
 looking at the circuit display will just see 'Bridge' rather than the full
 set of information.
  - Tor adds a new query API that allows us to get Bridge information in a
 similar fashion to how we currently get relay information. The repeated
 GETCONF for bridges goes away and we now for each id in the circuit, we
 just try querying bridge info and if that fails we then query relay info.
  - Tor Browser listens for the 'figured out the fingerprint for this
 bridge event' (which I believe currently just logs?) and maintains some
 in-memory map/cache of fingerprint to { type, ip, geolocation }. I'd
 really rather not do this.
  - Add a 'verbose' circuit query API, where we just provide the
 domain/nonce pair and you give us the required data all at once. This
 would simplify Tor Browser code and would require less back-and-forth
 between tor and Tor Browser.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32204>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs