Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

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

#33666: Investigate Snowflake proxy failures
-------------------------------------+------------------------
 Reporter:  cohosh                   |          Owner:  (none)
     Type:  defect                   |         Status:  new
 Priority:  High                     |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:  #19001                   |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------

Comment (by cohosh):

 My first thought here was to use a slight variation of #32938 to do a
 simpler probe that just tests the ability to open a datachannel. This
 could function similar to the probe test of the bridge added in #31391.

 My hesitancy for relying on this in the same way that we rely on the
 bridge is that it adds another single point of failure. If for some reason
 this probe test stops working, we will lose all of our proxies. I suppose
 the same is true for the broker or the bridge: if any of these stop
 working, snowflake essentially stops. But this increases the attack
 surface a bit.

 Obviously it's preferable to actually find out what is causing such a high
 failure rate in proxies and use that to inform what we do. Another thought
 I has was that if STUN is never successfully completing, the proxies will
 end up timing out ([https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/snowflake.js?id=ea01bf41c3011590938b079ed96c7b35cb40588b#n76
 here] and [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy-
 go/snowflake.go?id=ea01bf41c3011590938b079ed96c7b35cb40588b#n406 here])
 because the datachannel was never opened. We could do one of several
 things if a proxy reaches this state:
 1. log debug information and encourage the owner through the UI to file a
 Tor ticket with the log messages so we can figure out what's going on,
 2. keep track of how many times this happens, and if it always happens
 (the proxy sees no successful connections) disable the proxy and print out
 some debug messages,
 3. do a probe test only when the datachannel fails to open to check
 whether the proxy can open a datachannel with the probe point.

 These aren't necessarily mutually exclusive. Option (2) provides a vector
 for attack where an adversarial client can make a bunch of connections
 through proxies and simply never open a datachannel. Hopefully as long as
 honest client traffic is significantly higher than adversarial traffic,
 the proxy will see some successes and not trigger the disable condition.
 In any case, I think encouraging proxy owners to file a ticket if it
 happens too much is a good way to go here.

 Again, these techniques will only help against honest proxies that are
 trying their best but aren't helping users. I think that's the case for at
 least most of the proxies here because of the geographic distribution of
 failed snowflakes.

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