[tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Dec 12 20:52:06 UTC 2017


#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.0.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  030-backport, 031-backport,          |  Actual Points:
  regression, tor-bridge-client, s8-errors,      |
  tbb-wants                                      |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8-can
-------------------------------------------------+-------------------------

Comment (by gk):

 We debugged this a bit on IRC today and it turned out that a crucial part
 in this bug seems to be that one of the `obfs3` and one of the `obfs4`
 bridges share the same ID. So, if one chooses an `obfs3` bridge Tor
 Launcher issues a `SETCONF` command like
 {{{
 [12-12 16:21:14] TorLauncher DBUG: Sending Tor command: SETCONF
 UseBridges=1 Bridge="obfs3 109.105.109.163:38980
 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED" Bridge="obfs3
 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A"
 Bridge="obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239"
 Bridge="obfs3 169.229.59.75:46328
 AF9F66B7B04F8FF6F32D455F05135250A16543C9"
 Bridge="obfs3 169.229.59.74:31493
 AF9F66B7B04F8FF6F32D455F05135250A16543C9"
 }}}
 . When pressing `Cancel` during the bootstrap process and selecting the
 `obfs4` option instead, Tor Launcher is sending a similar `SETCONF`
 command. However, later on we easily get a bootstrap error like
 {{{
 Dec 12 17:21:35.000 [warn] Problem bootstrapping. Stuck at 85%:
 Finishing handshake with first hop. (DONE; DONE; count 1;
 recommendation warn; host A09D536DD1752D542E1FBB3C9CE4449D51298239 at
 83.212.101.3:80)
 }}}
 The ID A09D536DD1752D542E1FBB3C9CE4449D51298239 is used by one of the
 `obfs4` bridges as well (the IP is the same but the port is different
 (50002 in this case)). It seems things are working much better if I remove
 the `obfs3` bridge with A09D536DD1752D542E1FBB3C9CE4449D51298239 first
 before starting. I did some tests and I never ran into the bootstrap
 error. FWIW it is visible as well if one starts with `obfs4` first and
 switches to `obfs3`, although it seems the error does not pop up outright
 (as in the `obfs3` -> `obfs4` switch) but gets visible once I press
 `Cancel` in Tor Launcher after the bootstrap process is stuck.

 According to Nick the issue seems to be that Tor Browser will have a guard
 entry for the bridge it was using before but it seems the lookup which is
 done by fingerprint _and_ address is not working as expected.

 So, that's the error case in 4) in my comment:description. I am not sure
 about the stalling part yet. My current plan is to open a new ticket once
 all open issues related to that one are fixed/merged and I can still come
 up with a scenario to reproduce a stalled bootstrap process.

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


More information about the tor-bugs mailing list