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

[Tor Bug Tracker & Wiki]

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

Comment (by yawning):

 Replying to [comment:7 teor]:
 > Hmm, after thinking about this for a few days, I actually think picking
 another dummy IP address and hoping it keeps working in future is a
 brittle approach. I'd rather work out why tor is trying to connect to that
 address in the first place, when the pluggable transport should be the
 thing connecting to it, not tor.

 Because, the code assumes that every node has an IP address (reasonable,
 except for oddball PTs like meek).  How else are you going to identify
 nodes before you bootstrap in the general case anyway? (The relay
 fingerprint on Bridge lines is optional, which doesn't leave many other
 options...).

 > (Am I understanding how pluggable transports work?)
 >
 > 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".
  * Allow connections to  PT bridges on "internal addresses".
  * Pick a magic address for meek-like transports that bypasses the sanity
 check and document it as "the one true synthetic address to use".

 Out of those the first two options are more appealing to me, and are
 trivial to do...

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