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

 Replying to [comment:37 cohosh]:
 > Replying to [comment:36 teor]:
 > > Some users even struggle with Tor's 10-30 second timeouts, because
 they are on really slow links.
 > > Even mobile from Australia to Europe can take a few seconds.
 >
 > So Tor's timeout is 10-30 seconds?

 Hum, TIL tor has a
 [https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt?h=tor-0.4.1.6#n1376
 SocksTimeout] option. But it's supposed to be 120 s, not 30 s.
 >  SocksTimeout ''NUM''::
 >    Let a socks connection wait ''NUM'' seconds handshaking, and ''NUM''
 seconds unattached waiting for an appropriate circuit, before we fail it.
 (Default: 2 minutes)

 I'm not sure where the 30 s is coming from. Could it be
 LearnCircuitBuildTimeout or something like that? Anyway, you could test
 using an artificially high SocksTimeout, to see if the problem still
 happens.

 Replying to [comment:38 cohosh]:
 > > Anyway, you can always send a fake "Grant" response without waiting
 for a proxy to be available
 > Snowflake does the same [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/client/lib/snowflake.go#n31 here].

 No, what it's doing now is not quite what I mean. I mean putting the
 `socks.Grant` ''before'' the `snowflakes.Pop()` (or even inside
 `socksAcceptLoop`). If I'm not mistaken, `snowflake.Pop` is a blocking
 operation that doesn't return until an entire broker exchange has happened
 and a WebRTC connection is established. I mean optimistically calling
 `socks.Grant` on the incoming SOCKS connection immediately, even if we
 have 0 snowflakes available. Especially now that this sequencing branch
 exists, tor's SOCKS connection is not tied to any single WebRTC
 connection.

 > 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?

 Yes, I think this can work. (Something like IPv4/IPv6 "happy eyeballs.")
 My plan for a turbo tunnel adaptation is to basically do this, try sending
 through all available snowflakes at all times (using e.g. round robin),
 and if one doesn't work or drops packets, it's no problem. Even without
 multiplexing, you could race just the WebRTC rendezvous across 3
 snowflakes, then take the one that finishes first, and throw the others
 away.

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