#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs