Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

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

#24432: The meek<->moat tunneling isn't set up correctly
----------------------------------+--------------------------
 Reporter:  isis                  |          Owner:  isis
     Type:  defect                |         Status:  reopened
 Priority:  High                  |      Milestone:
Component:  Obfuscation/BridgeDB  |        Version:
 Severity:  Normal                |     Resolution:
 Keywords:  moat bridgedb-dist    |  Actual Points:
Parent ID:  #24689                |         Points:  2
 Reviewer:                        |        Sponsor:  SponsorM
----------------------------------+--------------------------

Comment (by isis):

 Replying to [comment:10 mcs]:
 > (I added dcf to the Cc in case he has any insight into problem 1 below).
 >
 > Thanks for your work on this Isis! I feel like we are very close to
 having a working system. Kathy and I have found two problems so far, but I
 am not ready to reopen this ticket yet because I am not sure what
 component is at fault.
 >
 > '''Problem 1:''' The meek tunnel does not work reliably for us.
 Specifically, if we use curl as the SOCKS client it seems to always work
 and if we use Tor Browser it does not. When we test with our own meek-
 server + BridgeDB, things also work fine. I am having trouble debugging
 the meek-client code, probably due to my lack of golang knowledge, but I
 wonder if there is an incompatibility between the meek-client we are
 running and the meek-server that you are running. What version of meek-
 server are you using at tor-bridges-hyphae-channel.appspot.com? Kathy and
 I are using a meek-client that was built from dcf's ​bug24642 branch (and
 I don't know of any recent changes to meek that would cause this kind of
 communication problem).
 >
 > Another data point: if I insert an socat pipe between the meek-client
 SOCKS port and Tor Browser, it started working. Maybe there is a data
 buffering issue at work here. All of our client side testing so far has
 been on macOS.

 Off the top of my head, I have no idea what this is about, other than
 perhaps the networking code in FF perhaps trying to do something "smart"
 which interacts badly with meek-server?

 Let me go see what versions are running on the appengine server and on
 polyanthum…

 The meek-server on polyanthum was from commit
 `017d0f33d7270ff102fe167f1c16def8b3e3be4a` from the end of March. That
 makes sense because that's around the time I did #16650. (I'm not sure if
 anything in the client/server implementations have changed enough to make
 this incompatible?)

 On the AppEngine instance, there should be a meek-reflector from the same
 period. I just logged in however and found this notice? I have no idea
 what this means.

 [[Image()]]

 > '''Problem 2:''' When we do manage to send a good `check` request (one
 that includes the correct response and challenge), we always receive a "No
 bridges available to fulfill request" response. We tried with both
 "vanilla" and "obfs4" transports. Here is a sample response:
 >   {"errors": [{"status": "Not Found", "code": 404, "detail": "No bridges
 available to fulfill request: None.", "version": "0.1.0", "type": "moat-
 bridges", "id": 6}]}
 > Is the Moat responder throttling things so we do not receive too many
 bridges? I don't think we have ever received any bridges from the
 production BridgeDB server via Moat, but even if we did I thought BridgeDB
 would send back the same set of bridges if we ask again. I can get new
 bridges repeatedly if I use a browser to interact with
 https://bridges.torproject.org/bridges?transport=obfs4.

 So the bridges are assigned to a distributor when they are first seen, and
 they can't be reassigned, in order to keep potential discoverability
 problems with any particular distribution method locally isolated.
 BridgeDB logs these assignments, and, grepping the latest assignments.log,
 it seems like it has 100 bridges for the moat distributor so far. (It's a
 known issue that adding a distributor would take a while to fill up with
 bridges since the way it works is that is has ratios and it assigns
 according to those ratios instead of bringing the levels to the correct
 ratios… I could fix that if we want.) But in any case, with 100 bridges,
 you should be getting at least 1 bridge back? Are you connecting to the
 meek-reflector over tor?

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