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

[Tor Bug Tracker & Wiki]

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

 Replying to [comment:19 dcf]:
 > Replying to [comment:10 mcs]:
 > > '''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.
 >
 > I was debugging this problem today and I traced the cause to Tor
 Browser's [https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.6.0esr-8.0-2&id=6d594cc227f153364b91e8310d59a07d7d6ce5f6
 optimistic SOCKS data patch] (#3875), which allows the browser to start
 sending application data right after sending its SOCKS request, before the
 proxy has sent back a reply saying that the connection was successful.

 Wow, thanks a lot for this analysis. Let me skip over it to jump to your
 conclusions part...

 > So a short-term workaround is to add an artificial delay into meek-
 client to prevent it from sending back the SOCKS response immediately. The
 delay has to go [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/meek-client/meek-
 client.go?h=bug24642&id=8c0e2c8601e87687a2f147a875753ac298b52a2e#n278 just
 before conn.Grant] in meek-client.go. I think that's the reason why it
 worked with a socat shim--the extra process tweaked the timing just
 enough.

 Given that the analysis shows that at least part of the problem is due to
 the patch itself and how it interacts with the other Firefox networking
 code I think we should back it out and rewrite it if we want to keep it.
 We actually have #19910 for that and I think the OP describes a scenario
 that is compatible with the one you are seeing.

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