[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs