#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs