[tor-bugs] #33693 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

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

#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
-----------------------------------------+--------------------
     Reporter:  arma                     |      Owner:  (none)
         Type:  defect                   |     Status:  new
     Priority:  Medium                   |  Milestone:
    Component:  Circumvention/Snowflake  |    Version:
     Severity:  Normal                   |   Keywords:
Actual Points:                           |  Parent ID:
       Points:                           |   Reviewer:
      Sponsor:                           |
-----------------------------------------+--------------------
 Snowflake's default bridge pretends to be on 0.0.3.0. It's a dummy address
 since snowflake-client knows how to connect to the right bridge and
 ignores the address that Tor tells it.

 But my Tor client still uses that bridge address to make decisions. For
 example, connection_is_rate_limited() decides "no, it isn't rate limited",
 because tor_addr_is_internal() says 0.0.3.0 is essentially part of
 localhost. And that choice has a cascading effect where when I attach my
 nyx to Tor Browser to graph bandwidth use ({{{nyx -i 9151}}}), the BW
 events all say "0 0" because my Tor hasn't sent or received any non-
 internal bytes.

 The quick fix is to keep using a dummy address, but to pick one that isn't
 an internal address. I confirmed that if I change snowflake's dummy
 address to 11.0.3.0, then connection_is_rate_limited() decides it's
 external, my BW events work again, and nyx gives me graphs. That is, Tor
 is smart enough to know that even though the connection is from the Tor
 client to the localhost snowflake client, the connection is "really" to
 the (non-localhost) destination bridge address.

 I confess that I don't know which "apparently routable but don't worry we
 won't actually connect to it, probably" address is the best choice here.
 :/

 The longer term answer is to have some other way to signal that it's a
 dummy address, or to change the PT interface so we don't need the fake
 address. But I don't think we need to wait for the longer term answer
 here.

 The reason I noticed this issue is because I am pondering lobbying for the
 Tor Browser folks to give me a tiny bandwidth graph (or activity spinner)
 somewhere in the browser, because I got a super slow snowflake, but I was
 still getting 5-10KBytes/s, and my page did load after like 90 seconds,
 but if I hadn't been staring at the
 {{{
 2020/03/23 09:33:05 Traffic Bytes (in|out): 9018 | 10981 -- (27
 OnMessages, 24 Sends)
 }}}
 lines I would have assumed that it was wedged.

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