Re: [tor-bugs] #25429 [Obfuscation/Snowflake]: Need something better than client's `checkForStaleness`

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25429: Need something better than client's `checkForStaleness`
-----------------------------------+---------------------------
 Reporter:  arlolra                |          Owner:  cohosh
     Type:  defect                 |         Status:  assigned
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:  Sponsor19
-----------------------------------+---------------------------

Comment (by cohosh):

 It looks there are 3 possible cases of things that happen:

  1. The client isn't requesting any traffic and isn't using the network

  Users may spend a long time while browsing a page or leave Tor Browser
 running in the background while performing other tasks and it will be a
 long time before they have more network requests to send. Snowflake's
 current behaviour is to timeout the connection and request new
 snowflake(s) every 30 seconds. This uses up network traffic and snowflake
 resources.

  '''Desired behaviour''': stop collecting snowflakes until the client has
 traffic to send (as in #21314). This of course means that we have to wait
 to construct an entirely new Tor circuit before the client can actually
 send their request. I'd suggest putting a fairly long timeout on this
 (tor-spec sets KeepaliveTimeout to 5 minutes by default)

  2. The proxy is subject to network interference and is completely
 unreachable.

  A shown in #30350, the snowflake client assumes that the proxy is
 reachable as soon as they receive the offer from the broker and attempt to
 open the DataChannel. We were seeing STUN messages being sent from the
 client with no response
 (https://trac.torproject.org/projects/tor/ticket/30350#comment:5).

  '''Desired behaviour''': We want to detect this and retry with a
 different snowflake as quickly as possible. An alternative would be to
 attempt to connect to multiple snowflakes (set `max` to > 1) to increase
 the chance of getting a good snowflake right away. I think we should have
 a different way of detecting this rather than the 30 second timeout that
 detects it now.

  3. The proxy is malicious, unreliable, or reachable but subject to
 network interference

  A snowflake proxy could stop processing traffic partway through a
 browsing session where the user is actively making requests. This could be
 a DoS performed by the proxy or the censor

  '''Desired behaviour''': We want to be able to detect this as quickly as
 possible and start sending traffic through another proxy. Again, we want
 something different than the current 30s timeout here. This is something
 that #25723 could help out with as well. If we had a sequencing and
 reliability layer, we could notice that our requests have not been
 acknowledged within some short (< 30s) timeout and retransmit them through
 a different proxy

 The current `checkForStaleness` works really well for case (1). I'd
 propose to keep it around for that purpose and lengthen the timeout to
 something closer to the 5 minute default of Tor relays.

 To handle (2) and (3) I think we want something like a
 sequencing/reliability layer that can also be extended for multiplexing
 across multiple proxies (#25723). I think a good way forward is to get
 this layer working for a single proxy to detect unreliability and blocking
 first and then move forward on multiplexing.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25429#comment:8>
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