[tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
-----------------------------------------------+---------------------------
 Reporter:  cohosh                             |          Owner:  cohosh
     Type:  task                               |         Status:
                                               |  needs_review
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Snowflake            |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID:                                     |         Points:  6
 Reviewer:  dcf                                |        Sponsor:
                                               |  Sponsor28-must
-----------------------------------------------+---------------------------

Comment (by cohosh):

 > Is it the timeout when tor sends a SOCKS request and is waiting for the
 "Grant" or "Reject" response? With the Snowflake protocol in place, tor
 should not be requesting new SOCKS sessions anyway -- because snowflake-
 client won't be closing its existing SOCKS connection every time it loses
 proxy connectivity. Anyway, you can always send a fake "Grant" response
 without waiting for a proxy to be available; that's what meek does and the
 PT protocol kind of forces that behavior on non-connection-oriented
 protocols like this.

 Snowflake does the same [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/snowflake.go#n31 here]. It's
 timing out because after granting the request, the SOCKS connection hasn't
 received any data in 30s if the user happens to get a bad snowflake. The
 connection isn't been closed on the PT side, it's being closed on the tor
 side it seems. So unless there's some way for the PT to send some kind of
 keep alive signal, there's no way for the SOCKS connection to tell the
 difference between a connection that's gone completely dead for some
 reason.

 Perhaps multiplexing is the way to go. What I was asking for with the
 short timeouts was maybe a bit misleading. I was thinking of trying to
 cycle really quickly through bad proxies before landing on a good one but
 that still takes time and doesn't seem like the right approach here. We
 could try sending data through a few proxies (maybe 3?) and then just use
 whichever snowflake gets the data to the server the fastest?

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