[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [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
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs