Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-11-04T14:18:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19610IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks2020-11-04T14:18:56ZteorIPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacksWhen an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback di...When an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback directories, fetching ~7500/500 = 15 sets of descriptors from 15 of the 25 IPv6 fallbacks.
We should improve this behaviour somehow, to avoid overloading the fallbacks. One simple way of doing this is selecting 200 fallbacks for 0.2.9 in legacy/trac#18828.
It's worth noting that this extra load only happens on bootstrap, when there are no cached microdescriptors. If an IPv6-only client has any IPv6 microdescriptors that match the current consensus, it will use those relays instead.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19608IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc2020-06-27T13:58:37ZteorIPv6-only clients can't fetch microdescriptors on 0.2.8.5-rcThere's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* b...There's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* but it's a consensus, so IPv6-only clients try to use it to find an IPv6 relay, and fail
A solution is to teach IPv6-only clients to get (at least some of) their descriptors from the fallback directories, at least until they have some IPv6 microdescriptors. Perhaps this should happen automatically when the entire consensus fails, but for some reason it doesn't.
I have no idea how we didn't catch this during testing - perhaps there were always cached descriptors? Perhaps we broke falling back to the fallbacks for descriptors?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19487Meek and ReachableAddresses2022-09-19T21:17:44ZcypherpunksMeek and ReachableAddressesThis came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `Fasci...This came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `FascistFirewall`. While the ports they can reach might be set correctly, when using `meek` `tor` sees the destination address as a fake destination. You end up with a log that looks like this:
```
NOTICE: Bridge at '0.0.2.0:1' isn't reachable by our firewall policy. Skipping.
```
This happens because they haven't defined `0.0.2.0:1` as being a reachable address, while in reality it's using (most likely) port 443 on some CDN, which might actually be defined reachable.
Maybe not a common issue but an interesting edge case that may be clarified, avoided, or documented somewhere.https://gitlab.torproject.org/tpo/core/tor/-/issues/18674Tor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes elimi...2020-07-27T19:10:04ZSebastian HahnTor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes eliminatedI suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.I suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18652ipv6 listener only, ipv4 source addresses2020-06-27T13:59:20ZTracipv6 listener only, ipv4 source addresses[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one,...[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one, if available.
Practically, if the address family of the listen port should be used as the address family of the outgoing socket that detects the local addess.
**Trac**:
**Username**: chadmillerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18394Allow relays to have an IPv6 DirPort on the same port as the IPv4 DirPort2020-06-27T13:59:31ZteorAllow relays to have an IPv6 DirPort on the same port as the IPv4 DirPortCurrently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Currently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18387Allow Listening on :: for IPv62020-06-27T13:59:31ZTracAllow Listening on :: for IPv6Running tor-win32-0.2.7.6, SocksPort and ORPort do not allow binding to "::1" for "all IPv6 interfaces". They do allow binding to "0.0.0.0" for "all IPv4 interfaces" though. This ticket is a feature request to allow binding to "::1" for ...Running tor-win32-0.2.7.6, SocksPort and ORPort do not allow binding to "::1" for "all IPv6 interfaces". They do allow binding to "0.0.0.0" for "all IPv4 interfaces" though. This ticket is a feature request to allow binding to "::1" for "all IPv6 interfaces" in torrc.
**Trac**:
**Username**: DJXTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18357HiddenServicePort IPv6 broken2020-06-27T13:59:33ZTracHiddenServicePort IPv6 brokenHi,
In reference to: legacy/trac#6551 and legacy/trac#12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
Hidden...Hi,
In reference to: legacy/trac#6551 and legacy/trac#12670.
I was not having much luck setting up a Hidden Service. I found later that worked when I used 127.0.0.1:80 instead of [::1]:80.
I then tested v6 and v4, side-by-side:
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 81 [::1]:80
Port 80 worked, 81 did not. I checked a few times with curl locally and with tor browser.
I'm running FreeBSD 10.2. Had a pretty slim configuration when I tried this. Verified with fetch and sockstat that indeed the service was listening on ::1 (::0/0, actually).
Thank you,
Teran
**Trac**:
**Username**: sega01Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18051directory_send_command should decorate IPv6 addresses to avoid port ambiguity2020-06-27T13:59:47Zteordirectory_send_command should decorate IPv6 addresses to avoid port ambiguityIn legacy/trac#17573, we discovered that directory_send_command doesn't quote IPv6 addresses in directory URLs. This could cause issues with the ":port" suffix for directories that aren't on the default port 80.In legacy/trac#17573, we discovered that directory_send_command doesn't quote IPv6 addresses in directory URLs. This could cause issues with the ":port" suffix for directories that aren't on the default port 80.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17952Make address family search via ioctl more accurate on obscure platforms2020-07-17T11:11:50ZteorMake address family search via ioctl more accurate on obscure platformsThe following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http:...The following address family search functions only return an IPv6 address on some platforms:
* ioctl(.,SIOCGIFCONF,.) only returns IPv4 addresses, except:
* on HP-UX and Solaris, which support AF_INET6 with SIOCGLIFCONF
* see http://www.manpages.info/sunos/if_tcp.7.html
* on AIX, using the sa_len field in struct sockaddr to distinguish between IPv4 and IPv6 addresses
* on MVS and z/OS, which support AF_INET6 with SIOCGIFCONF6 / __net_ifconf6header_s
* see http://www-01.ibm.com/support/docview.wss?uid=isg1PK22885 for details
* on these platforms, we should try AF_INET, then AF_INET6, and then both addresses should be returnedTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17951Make address family search via UDP socket hack more accurate2020-06-27T13:59:51ZteorMake address family search via UDP socket hack more accurateThe following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it s...The following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it should be call get_interface_address6_via_udp_socket_hack with AF_INET, and then AF_INET6, and then both addresses should be returnedTor: 0.2.8.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/17948HiddenServicePort should connect to localhost by default2020-06-27T13:59:52ZteorHiddenServicePort should connect to localhost by defaultHiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's i...HiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's in 127.0.0.0/8 or [::1], and use the IPv4 address first for compatibility with existing configurations
* default to 127.0.0.1 if that exists
* default to [::1] if 127.0.0.1 does not exist
This is not a security issue, as it results in a failed hidden service connection on unusual configs. It's a minor usability issue.
(Split from legacy/trac#17901 / legacy/trac#11360.)Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17907Modify clients to consistently send N% of initial consensus requests to the a...2020-06-27T13:59:55ZteorModify clients to consistently send N% of initial consensus requests to the authoritiesWe currently use the directory authority statistics to estimate the number of clients in the Tor network.
But fallback directories will handle initial consensus downloads in future releases.
So, to preserve client statistics, we can mo...We currently use the directory authority statistics to estimate the number of clients in the Tor network.
But fallback directories will handle initial consensus downloads in future releases.
So, to preserve client statistics, we can modify Tor clients to make a certain small percentage (1%?) of initial consensus downloads to the directory authorities. If we scale the authority downloads from each Tor release by this factor, we can estimate the number of clients.
This is particularly important for client IPv6 bootstrap (legacy/trac#17840), as only some authorities and fallbacks have IPv6 (and the proportion of fallbacks is lower than the proportion of authorities).
We could change the meaning of DirAuthorityFallbackRate to "the authorities see this proportion of queries", or implement another option, and document the interaction with DirAuthorityFallbackRate.
(I think the second option is better, but we'd end up essentially obsoleting DirAuthorityFallbackRate.)Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17889Make ClientPreferIPv6ORPort apply to bridge clients2020-06-27T13:59:56ZteorMake ClientPreferIPv6ORPort apply to bridge clientsAfter legacy/trac#17840, clients that don't use bridges will select ORPorts using ClientPreferIPv6ORPort.
We could do this for bridges as well, by modifying the new function fascist_firewall_choose_address_base:
* use ClientPreferIPv6OR...After legacy/trac#17840, clients that don't use bridges will select ORPorts using ClientPreferIPv6ORPort.
We could do this for bridges as well, by modifying the new function fascist_firewall_choose_address_base:
* use ClientPreferIPv6ORPort to choose a preferred address for bridge clients,
* but ignore the "preferred address only setting", so that bridge users always get an address if there is one available.
I don't want to do this as part of legacy/trac#17840, because I'm not sure if it's really necessary - bridges just seem to work ok as-is.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17863Fixes to IPv6 address handling2020-06-27T13:59:57ZteorFixes to IPv6 address handlingI've made some fixes to IPv6 address handling:
* make address policy assume_action work for []-quoted IPv6 addresses
* unquoted addresses are ambiguous, because of the port separator ":", and "accept" starting with 4 hex digits
* limit...I've made some fixes to IPv6 address handling:
* make address policy assume_action work for []-quoted IPv6 addresses
* unquoted addresses are ambiguous, because of the port separator ":", and "accept" starting with 4 hex digits
* limit IPv6 mask bits to 128
* warn when comparing against an AF_UNSPEC address in a policy
* no code wants this to happen, and it produces unexpected results
Branch coming soon.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17854Use ClientIPv4 and ClientIPv6 to select a bridge address2020-06-27T13:59:57ZteorUse ClientIPv4 and ClientIPv6 to select a bridge addressIf a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is r...If a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is relevant here.)
This code works as-is, so I don't see any reason to change it urgently.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17849Warn if single-stack IPv4/IPv6 clients have very restricted guard choices2020-06-27T13:59:58ZteorWarn if single-stack IPv4/IPv6 clients have very restricted guard choicesYawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Yawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17845Add unit tests for IPv6 relay descriptors2020-07-27T18:24:42ZteorAdd unit tests for IPv6 relay descriptorsOnce chutney can verify using relays on IPv6 (legacy/trac#17011/legacy/trac#17153), we should update the unit tests to use descriptors that contain IPv6 addresses in "or-address" lines.
This will allow us to unit test legacy/trac#17840 ...Once chutney can verify using relays on IPv6 (legacy/trac#17011/legacy/trac#17153), we should update the unit tests to use descriptors that contain IPv6 addresses in "or-address" lines.
This will allow us to unit test legacy/trac#17840 and various other tickets.
From legacy/trac#17840:
* nodelist_set_consensus: setting ipv6_preferred correctly based on ClientUseIPv6, ClientPreferIPv6ORPort, and ClientUseIPv4.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17840Add a minimal implementation of ClientUseIPv4 so IPv6-only clients can bootstrap2020-08-11T12:13:35ZteorAdd a minimal implementation of ClientUseIPv4 so IPv6-only clients can bootstrapWhen Tor bootstraps, it connects to directory servers on their IPv4 address, regardless of the ClientUseIPv6 option.
We can add a ClientUseIPv4 option, and set it to 1 by default. (This needs a config check: reject the config if ClientU...When Tor bootstraps, it connects to directory servers on their IPv4 address, regardless of the ClientUseIPv6 option.
We can add a ClientUseIPv4 option, and set it to 1 by default. (This needs a config check: reject the config if ClientUseIPv4 and ClientUseIPv6 are both 0.)
Then we can add connection_get_address_family_for_purpose(), which returns the address family that should be used by outgoing connections. In this minimal implementation, we'll return AF_INET, unless ClientUseIPv4 is 0 and ClientUseIPv6 is 1 (an IPv6-only client).
For the moment, we'll ignore ClientPreferIPv6ORPort in connection_address_family_for_purpose. Once IPv6-only clients can bootstrap, we'll find out if the existing implementation of ClientPreferIPv6ORPort works.
This will implement parts of legacy/trac#9068, but only the minimal functionality needed to decide whether we are allowed to connect via IPv4 or IPv6. (There are many clever things we could do on dual-stack clients in connection_address_family_for_purpose(), to guess which IP version to use, or to alternate IP versions to find the best one. Some of these designs are described in legacy/trac#9068 and legacy/trac#17834. But first we need to get IPv6-using and IPv6-only clients bootstrapping.)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17835Make ClientPreferIPv6ORPort smarter2020-07-27T18:24:51ZteorMake ClientPreferIPv6ORPort smarterIt's hard for users on dual-stack machines to know whether their IPv4 or IPv6 connections provides better connectivity or censorship-resistance.
Tor could help with this by:
* Making ClientPreferIPv6ORPort/DirPort into an autobool, and ...It's hard for users on dual-stack machines to know whether their IPv4 or IPv6 connections provides better connectivity or censorship-resistance.
Tor could help with this by:
* Making ClientPreferIPv6ORPort/DirPort into an autobool, and setting the default to auto (infer), rather than 0 (IPv4)
* Infer initial IPv4/IPv6 preference by looking at the machine's network interfaces, and:
* Ignoring localhost (tor_addr_is_localhost) and link-local addresses (a new tor_addr_is_link_local)
* Checking for (other) private addresses (tor currently considers link-local addresses private, this shouldn't change in the rest of the codebase, but it is important to distinguish here, as IPv4/IPv6 hosts with no IPv6 connectivity still auto-configure a link-local IPv6 address)
* Checking for publicly routable addresses
* Preferring IP versions that have a public address, over those that have a private address
* (I'd also say to avoid IP versions that only have localhost or link-local addresses, and don't use IP versions that have no addresses, but that might cause issues with proxies, or with machines that prohibit enumeration of local addresses.)
* Repeat these checks every N minutes in case the network interfaces have changed (relays do this every 20 minutes at the moment)
* Infer a preference for IPv4 or IPv6 based on the number of failed connections
* Globally track counts of attempted IPv4 and IPv6 connections
* Globally track failures of attempted IPv4 and IPv6 connections
* If there have been at least M attempts (2? 3?) on (one? each?) IP version, then:
* If an IP version has 100% failure, avoid it
* IP an IP version has a significantly (2x?) larger failure rate, avoid it
I'm deferring this to 0.2.9 because:
* IPv4/IPv6 Tor clients might work fine without any of these changes.
* It's complex code, and it's not clear that it's the best way to determine preferred IP versions. (Let's get some experience with dual-stack clients first.)
* We only have 4/9 authorities and ~25% of fallback directory mirrors on IPv6, so let's prefer IPv4 by default at the moment for load-balancing reasons. (For similar reasons, ClientUseIPv6 could default to 1 in future, but now might not be a good time to do that. However, Tor Browser sets it to 1 at the moment.)Tor: unspecified