Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-09-16T14:30:20Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26436Check uses of CMP_SEMANTIC for IP addresses2021-09-16T14:30:20ZteorCheck uses of CMP_SEMANTIC for IP addressesFrom legacy/trac#24546 comment 1:
We should also audit all uses of tor_addr_compare(a1, a2, CMP_EXACT) to see if they should be CMP_SEMANTIC instead.
The current uses of CMP_SEMANTIC seem reasonable, but not essential: they code would s...From legacy/trac#24546 comment 1:
We should also audit all uses of tor_addr_compare(a1, a2, CMP_EXACT) to see if they should be CMP_SEMANTIC instead.
The current uses of CMP_SEMANTIC seem reasonable, but not essential: they code would still work if we rejected mapped addresses and did exact comparisons instead.https://gitlab.torproject.org/tpo/core/tor/-/issues/9067Choice of address and match of fascist_firewall_allows_address* need to consi...2020-08-11T12:13:35ZNick MathewsonChoice of address and match of fascist_firewall_allows_address* need to consider ipv6Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I k...Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I know.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31545CID 1452819: nul-terminated string handling, possibly spurious2020-06-27T13:49:33ZteorCID 1452819: nul-terminated string handling, possibly spuriousBug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
...Bug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
76 if (has_addr) {
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a null-terminated string.
77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
78 }
79
80 return buf;
81 }
82
/src/feature/nodelist/describe.c: 70 in format_node_description()
64 cp += 4;
65 }
66 if (addr32h) {
67 struct in_addr in;
68 in.s_addr = htonl(addr32h);
69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-terminated string.
70 cp += strlen(cp);
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
```
I think the best fix for this issue is using strncpy() rather than memcpy().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24000circuit_send_intermediate_onion_skin() and extend_cell_format() should check ...2020-07-28T14:20:42Zteorcircuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in legacy/trac#23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the exte...When circuit_send_intermediate_onion_skin() and extend_cell_format() handle tor_addr_t, they assume they are IPv4.
But in legacy/trac#23502, we almost wrote code that sent them an IPv6 address. In this case, they put 0.0.0.0 in the extend cell, but they could issue a BUG() warning and refuse to send the cell instead.
Or they could send a proper IPv6 link specifier where the extend cell allows it.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24736Clear the address when fascist_firewall_choose_address_base() can't find an a...2021-08-23T15:17:07ZteorClear the address when fascist_firewall_choose_address_base() can't find an addressWe should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to legacy/trac#23874.We should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to legacy/trac#23874.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21506Client with current microdesc consensus but no descriptors chooses down fallb...2020-06-27T13:57:08ZteorClient with current microdesc consensus but no descriptors chooses down fallback every timeTor 0.2.9.9 doesn't have the fix for a similar issue in legacy/trac#20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every tim...Tor 0.2.9.9 doesn't have the fix for a similar issue in legacy/trac#20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This really shouldn't happen: the client should choose a different relay every time.
My guess is that this relay is chosen because it's down, and all the up relay descriptors are unavailable. This is pathological behaviour.
I think we fixed it in 0.3.0.2-alpha with the patch to legacy/trac#20996, but I'm logging this bug just in case.
http://pastebin.ca/3769463Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5537client_check_address_changed() looks likely to do badly with ipv6 connections2020-06-27T14:06:33ZNick Mathewsonclient_check_address_changed() looks likely to do badly with ipv6 connectionsClients call client_check_address_changed() on every outgoing connection. This function then does a getsockname() on the socket using a sockaddr_in, and logs a warnings if the getsockname() fails.
Unless I'm missing something fundament...Clients call client_check_address_changed() on every outgoing connection. This function then does a getsockname() on the socket using a sockaddr_in, and logs a warnings if the getsockname() fails.
Unless I'm missing something fundamental, this will spam users' logs with a bunch of EFAULT errors.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21499client_dns_incr_failures while passing not hostname but only IP2020-07-28T02:49:55ZTracclient_dns_incr_failures while passing not hostname but only IPI frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [...I frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:22.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:30.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:45.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:47.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
**Trac**:
**Username**: acceleraTorTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6757ClientPreferIPv6ORPort not honoured when running with bridges2020-06-27T14:05:49ZLinus Nordberglinus@torproject.orgClientPreferIPv6ORPort not honoured when running with bridgesSince get_configured_bridge_by_routerinfo() returns the same bridge
regardless of which routerinfo we pass to it, the first found
(seemingly the one configured first in the config file).
One effect of this is that rewrite_node_address_f...Since get_configured_bridge_by_routerinfo() returns the same bridge
regardless of which routerinfo we pass to it, the first found
(seemingly the one configured first in the config file).
One effect of this is that rewrite_node_address_for_bridge() will
prefer whatever is listed first. Looking at ClientPreferIPv6 wouldn't
make sense here since we come here once (only one routerinfo is
received), unless we start calling it for every configured
bridge. That doesn't seem like the right thing though.
Note that the idea of having ipv6_preferred as a property of the
node_t is that we'd like to be able to change its value, per relay,
when we learn about how we have been in touch with the relay.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2021-08-23T15:17:07ZteorClients should check IPv4 and IPv6 subnets when choosing circuit pathsCurrently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Currently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21346Clients with NoIPv4Traffic should only choose IPv6-supporting Exits2020-06-27T13:57:17ZteorClients with NoIPv4Traffic should only choose IPv6-supporting ExitsTor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit whe...Tor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit when NoIPv6 traffic is set).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23827Clients/Relays: Use IPv6 Addresses from microdesc consensus2020-06-27T13:55:19ZteorClients/Relays: Use IPv6 Addresses from microdesc consensusClient/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Client/Relay Implementation for legacy/trac#20916.
We need to use the IPv6 addresses from consensuses with versions that implement legacy/trac#23826, and ignore microdesc IPv6 addresses.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6763Combine "m" lines with identical hash values2020-06-27T14:05:49ZLinus Nordberglinus@torproject.orgCombine "m" lines with identical hash valuesdirserv_generate_networkstatus_vote_obj() recently (or soon to be,
depending on how you see it -- it sits in my branch bug6363_5535)
started generating two "m" lines in votes, one for consensus methods
8-13 and one for method 14 ("a" lin...dirserv_generate_networkstatus_vote_obj() recently (or soon to be,
depending on how you see it -- it sits in my branch bug6363_5535)
started generating two "m" lines in votes, one for consensus methods
8-13 and one for method 14 ("a" lines).
For relays without an IPv6 address (i.e. not including an "or-address"
line in their descriptor), the two hashes will be identical.
As an optimisation we could combine two "m" lines with identical hash
values. As an example, instead of saying
```
"m 1,2,3 H1"
"m 4,5 H1"
```
we would say
```
"m 1,2,3,4,5 H1"
```
but still say
```
"m 1,2,3 H1"
"m 4,5 H2"
```
This affects the size of the votes only and don't affect bandwidth
consumption for ordinary relays or clients in any way.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25245Crash in assert_connection_ok when changing Exit options2020-06-27T13:54:09ZtoralfCrash in assert_connection_ok when changing Exit optionsGot this today:
```
Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || connection_is_writing(con...Got this today:
```
Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || connection_is_writing(conn) || conn->write_blocked_on_bw || (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ) failed; aborting. (on Tor 0.3.3.2-alpha efc105716283bbdf)
```
Before I changed the config from
ExitRelay 1
IPv6Exit 1
to
#ExitRelay 1
#IPv6Exit 1
and a little bit later to
ExitRelay 0
IPv6Exit 0
and run a kill -HUP (after every config change)Tor: 0.3.5.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34068Decide how to handle control port events for IPv6 reachability self-tests2020-10-22T15:12:32ZteorDecide how to handle control port events for IPv6 reachability self-testsThe control spec has two reachability self-test events.
Here is how they are specified:
```
CHECKING_REACHABILITY
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We're going to start testing the reachability of our extern...The control spec has two reachability self-test events.
Here is how they are specified:
```
CHECKING_REACHABILITY
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We're going to start testing the reachability of our external OR port
or directory port.
REACHABILITY_SUCCEEDED
"ORADDRESS=IP:port"
"DIRADDRESS=IP:port"
We successfully verified the reachability of our external OR port or
directory port (depending on which of ORADDRESS or DIRADDRESS is
given.)
```
And here is what tor actually sends:
```
CHECKING_REACHABILITY ORADDRESS=IPv4:port
CHECKING_REACHABILITY DIRADDRESS=IPv4:port
REACHABILITY_SUCCEEDED ORADDRESS=IPv4:port
REACHABILITY_SUCCEEDED DIRADDRESS=IPv4:port
```
When we add IPv6 reachability events, we could break some (buggy) control parsers with:
```
CHECKING_REACHABILITY ORADDRESS=[IPv6]:port
REACHABILITY_SUCCEEDED ORADDRESS=[IPv6]:port
```
How should we handle this change?David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24604Decorate IPv6 addresses in connection_t->address to avoid ambiguity2020-07-28T16:16:07ZteorDecorate IPv6 addresses in connection_t->address to avoid ambiguityCurrently, connection_t->address can be in one of three formats:
* hostname: www.example.com
* IPv4: 1.1.1.1
* IPv6: 2003::0001
Tor often uses this address with a port like this:
* hostname: www.example.com:1234
* IPv4: 1.1.1.1:1234
* I...Currently, connection_t->address can be in one of three formats:
* hostname: www.example.com
* IPv4: 1.1.1.1
* IPv6: 2003::0001
Tor often uses this address with a port like this:
* hostname: www.example.com:1234
* IPv4: 1.1.1.1:1234
* IPv6: 2003::0001:1234
The IPv6 case is ambiguous, and we should fix it.
One way of fixing it is to provide a flag if address is an IPv6 literal, and a function to format address and port. (Unfortunately, we can't always decorate IPv6 addresses, because that would cause bugs in other code and in controllers.)
Then we would need to go through every instance of `conn->address` and find the ones that use a port. This may also require a spec update, like legacy/trac#24603.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6770Default value for AuthDirPublishIPv6 not honoured2020-06-27T14:05:48ZLinus Nordberglinus@torproject.orgDefault value for AuthDirPublishIPv6 not honouredAuthDirPublishIPv6 is AUTOBOOL.
AUTOBOOL defaults to -1.
We check AuthDirPublishIPv6 like this
```
options->AuthDirHasIPv6Connectivity == 0
```
in two places where we want to test whether it's "unset" or not. This
test will fail fo...AuthDirPublishIPv6 is AUTOBOOL.
AUTOBOOL defaults to -1.
We check AuthDirPublishIPv6 like this
```
options->AuthDirHasIPv6Connectivity == 0
```
in two places where we want to test whether it's "unset" or not. This
test will fail for AuthDirPublishIPv6 being -1.
After an interesting discussion with Roger on IRC, I suggest we make
this option BOOL.
The motivation is that we should have AUTOBOOL options only for things
decided from information from the consensus or the operating system
we're running on. Once we have code for autodetecting IPv6 support
from the OS we can turn it back into an AUTOBOOL again.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-27T13:47:56ZteorDefer "PreferIPv6 by default" to 0.4.4In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement ...In legacy/trac#32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in legacy/trac#33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since legacy/trac#32637, we have also merged:
* legacy/trac#33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* legacy/trac#32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/4806Detect and warn when running IPv6-using client without IPv6 address privacy2021-06-18T18:25:22ZNick MathewsonDetect and warn when running IPv6-using client without IPv6 address privacyLots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 494...Lots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 4941), but not all clients will know where it is, or know how to turn it on.
That's problematic for users on laptops or other mobile devices, since their MAC address provides a way to tell it's still them as they move around the network.
Perhaps when Tor is running as a client, we should detect whether the address(es) we're using on outbound connections match any MAC address, and warn if so. (Without root, we can't do more than warn and suggest a workaround.)
On Windows, it's part of the info we get from GetAdaptersAddresses(). On Linux and OSX this info *seems* to be available via getifaddrs(): we just need to check for AF_PACKET addresses on Linux and AF_LINK addresses on Mac. BSDs seem to do the same thing as OSX here.
Failing that, on Linux, we can learn the MAC address of a socket with ioctl(SIOCGIFHWADDR). On OSX, it looks like we might need to mess around with the IOKit framework and a chain of twisty little calls that start with IOServiceMatching and end no place good.
We'll need to suggest some action for the user to take. For a relay, no action is necessary. For a bridge, I'm not too sure. For a client, the OSX and FreeBSD fix appears to be "sysctl -w net.inet6.ip6.use_tempaddr=1 " ; On Linux, it's maybe "sysctl net.ip6.conf.if.use_tempaddr=2". On Windows, it's probably somthing fiddly.