[tbb-bugs] #18517 [Tor]: meek is broken in Tor Browser 6.0a3

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Mar 23 02:47:50 UTC 2016


#18517: meek is broken in Tor Browser 6.0a3
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
     Type:  defect                               |  team
 Priority:  Very High                            |         Status:
Component:  Tor                                  |  needs_review
 Severity:  Normal                               |      Milestone:  Tor:
 Keywords:  regression must-fix-before-028-rc    |  0.2.8.x-final
  meek                                           |        Version:  Tor:
Parent ID:                                       |  0.2.8.1-alpha
 Reviewer:                                       |     Resolution:
                                                 |  Actual Points:
                                                 |         Points:
                                                 |        Sponsor:  None
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:8 yawning]:
 > Replying to [comment:7 teor]:
 > > I think what tor should do is:
 > > * if a transport is specified in the Bridge line, and that transport
 corresponds to a ClientTransportPlugin line, tor should pass the address
 in the bridge line to the pluggable transport, and not try to connect to
 that address itself. (The pluggable transport is free to use [obfsproxy]
 or ignore [meek] that address.)
 >
 > This is what it used to do before it changed it, the "decide if need to
 pass it onto a PT" is done at the last possible moment.  What your code
 change effectively does is add "before passing the address to the PT (if
 applicable), check that it is not internal" (See:
 connection_or.c:`connection_or_connect()`).
 >
 > This change also breaks normal (non-PT) bridges hosted on an internal
 network, but I'm not sure if that's a common use case for actual users.
 It's rather common for me to run a bridge on the same host (communicating
 over the loopback interface) for testing, but I only need to edit 15 or so
 torrc files....
 >
 > The solutions I can think of off the top of my head are:
 >
 >  * Allow connections to  *all* bridges on "internal addresses".

 I think allowing bridges on internal addresses is a good fix for this.

 (And since they're configured in the torrc, this doesn't open any security
 holes. Bridge addresses can be updated from bridgedb, but if bridgedb
 started returning broken addresses, then that's not an issue clients can
 defend against.)

 Please see my branch bug18517 at https://github.com/teor2345/tor.git
 It fixes this issue and clarifies the corresponding entries in the tor man
 page.
 It needs to go in tor-0.2.8-rc, target date end of March.

 dcf, sorry that I've flipped this issue from tor to tor browser and back.
 Which one do you want to make a separate ticket for?

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


More information about the tbb-bugs mailing list