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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 dcf):

 (Conflicted with yawning's comment:8, posting anyway.)

 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.
 >
 > (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.)

 Actually that's how it works now. tor does not connect to the address.
 (That makes sense, because the transport might not even use TCP, for
 example.) tor passes the address to the pluggable transport executable
 though a SOCKS interface, roughly the same as if tor were connecting
 through an upstream proxy.

 In the case of obfs*, the bridge IP address also happens to be the address
 that the transport client should connect to, and it's an ordinary TCP
 connection. For meek, the transport client ignores the IP address, because
 the decision of what IP address to connect to is configured globally at
 the CDN, not at each client.

 I think tor is confused because it associates the bridge IP address with
 the connection, or something, and it rejects the connection even though
 it's not actually directly connecting to the IP address. Maybe the
 restriction on what IP addresses may be connected to should be relaxed in
 the case you cited above (Bridge configured with a matching
 ClientTransportPlugin).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18517#comment:9>
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