[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

Mon Mar 23 17:32:01 UTC 2020

#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                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------

Comment (by dcf):

 Great find, arma. Here is some background on this and related issues.

 * [[#18517|#18517 meek is broken in Tor Browser 6.0a3]]\\
   Commit
 [https://gitweb.torproject.org/tor.git/commit/?id=23b088907fd23da417f5caf2b7b5f664f317ef4a
 23b08890] in tor temporarily broke meek's 0.0.2.0 address in the course of
 trying to fix unrelated bugs. It added a test for `tor_addr_is_internal`
 to `circuit_handle_first_hop`. There's discussion there of what address to
 use that tor won't consider internal--it's not guaranteed that tor will
 ever permanently reserve a safe set of addresses for us--but the best
 candidate seems to be [https://tools.ietf.org/html/rfc5737 192.0.2.0/24],
 a range reserved for documentation. In the end, tor's code was changed to
 allow bridges on internal addresses, which resolved the problem even
 though meek doesn't ''actually'' connect to a bridge on an internal
 address.
 * [[#18611|#18611 Improve semantics for pluggable transports with dummy
 addresses]]\\
   Was an attempt to formalize the situation around dummy addresses, and
 provide guidance as to what transport authors should do if they don't use
 the address field in the bridge line. phw suggested an `implicit` token in
 the bridge line that would tell tor not to consider that the bridge line
 address is actually being connected to.
 * [[#19487|#19487 Meek and ReachableAddresses]]\\
   A related address-handling bug: if you configure `ReachableAddresses`
 such that a dummy address is considered not reachable, tor will not even
 try connecting to the transport. (Not knowing that the transport has no
 intention of trying to connect to that address.) teor has a patch there to
 ignore `ReachableAddresses` for bridges with transports, but it fell off
 the review pipeline.
 * [[#25528|#25528 When ClientTransportPlugin is missing, tor connects
 directly to bridge addresses, even if they have a transport name]]\\
   Shows the danger of putting a routable address in a bridge line, even if
 ignored by the transport. If there are errors elsewhere in torrc, tor may
 make a direct TCP connection to whatever address is there, instead of
 passing it to a pluggable transport proxy. This is what I was trying to
 prevent by using an obviously invalid address like 0.0.3.0: in the event
 of error, tor still tries to connect directly to the address, but it fails
 at the OS level with an "Invalid argument" error and no traffic leaves the
 machine.

 And some history on how we arrived at the 0.0.''X''.0:1 pattern for dummy
 addresses. With flash proxy back in 2011, there was originally was no such
 thing as `ClientTransportPlugin` or transport-aware bridge lines, so you
 had to fake it with `Socks4Proxy` and a SOCKS-speaking local transport
 program. It happened that the address of the local SOCKS proxy was
 127.0.0.1:9001, and I put that address in both `Socks4Proxy` and `Bridge`
 lines:
 https://gitweb.torproject.org/flashproxy.git/tree/README?id=d40953b0b2164548d06964f2e98087e2dd528f31#n53
 {{{
 UseBridges 1
 Bridge 127.0.0.1:9001
 Socks4Proxy 127.0.0.1:9001
 }}}
 Later I decided it was confusing to have the same address in both places
 when one of them is ignored and one is not, so I changed the ignored one
 to 0.0.0.0:1. I didn't document why I chose the port number 1, but I'm
 pretty sure it's because tor internally uses port 0 as a sentinel in some
 places.
 https://gitweb.torproject.org/flashproxy.git/commit/?id=bf51cf0b761214e39f635d14451582d27a8915ab
 But 0.0.0.0 didn't work well because that is `AF_UNSPEC`, which tor treats
 specially in various places (including in `connection_is_rate_limited` in
 comment:2). I think I first tried 0.0.0.1 after that, but that one is no
 good because 0.0.0.''nonzero'' is a
 [https://en.wikipedia.org/wiki/SOCKS#SOCKS4a SOCKS4a] magic value
 indicating a hostname. So I switched it to 0.0.''X''.0:1.
 https://gitweb.torproject.org/flashproxy.git/commit/?id=fdcb2d1382b430565afbcd5dcfad829479c0bb7b
 Since then I've been incrementing ''X'' with each new transport that uses
 dummy addresses. This is because if we use the same dummy address for two
 transports that actually connect to different bridges, tor will complain
 about seeing two different fingerprints for the "same" bridge, because
 internally it keys its tables by IP:port.

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