Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-05-02T20:28:11Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7478Allow routersets to include/exclude nodes by IPv6 address2022-05-02T20:28:11ZNick MathewsonAllow routersets to include/exclude nodes by IPv6 addressRight now, routerset_contains_*() and friends only looks at a single tor_addr_t. But nodes now can have more than one address.
The simple rule here would be to have a node considered to be a member of a routerset if *any* of its addres...Right now, routerset_contains_*() and friends only looks at a single tor_addr_t. But nodes now can have more than one address.
The simple rule here would be to have a node considered to be a member of a routerset if *any* of its addresses is contained in the routerset. That would make ExcludeNodes work right, but could get surprising behavior with ExitNodes and the like.
A less simple rule would be to have slightly different semantics for 'include' and 'exclude' routersets, but I don't much like that option: it also seems likely to surprise.
The least simple option would be to treat a node as partially in a set if one of its addresses is included and another isn't. That's a worst-case option IMO: it's likely to be complex and error-prone.https://gitlab.torproject.org/tpo/core/tor/-/issues/6939Missing IPv6 ORPort reachability check2021-07-09T17:22:51ZshamrockMissing IPv6 ORPort reachability checkIssue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-05...Issue:
Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.
Tor does log a corresponding test for an IPv4 ORPort.
Environment:
Debian squeeze amd64, latest patches
Tor version 0.2.4.2-alpha (git-0537dc6364594474)
How to reproduce:
- configure Tor with both IPv4 and IPv6 IP addresses and OrPorts.
- start Tor
- the Tor log file will show a test to determine if the IPv4 OrPort is reachable, but not if the IPv6 ORPort is reachable.
- (this particular system was configured as a bridge)
Expected Behavior:
The user might expect to see a log entry for IPv6 that corresponds to the following log entry for IPv4:
"Sep 22 11:09:21.000 [notice] Now checking whether ORPort [host's IPv4 address]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)"Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6884Warning about preferred bridge address lies2020-06-27T14:05:38ZLinus Nordberglinus@torproject.orgWarning about preferred bridge address liesWhen the ClientUseIPv6 option was added (commit e04e1a2e) the logic
for what a preferred OR port is changed. The warning about which OR
port is prefered rewrite_node_address_for_bridge() now may say
confusing things like "Will prefer IPv...When the ClientUseIPv6 option was added (commit e04e1a2e) the logic
for what a preferred OR port is changed. The warning about which OR
port is prefered rewrite_node_address_for_bridge() now may say
confusing things like "Will prefer IPv6 port" and then print an IPv4
port.
The address is correct. The address family, "IPv4" or "IPv6" may be wrong.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6880Don't do reachability testing over IPv6 when AuthDirHasIPv6Connectivity isn't...2020-06-27T14:05:38ZLinus Nordberglinus@torproject.orgDon't do reachability testing over IPv6 when AuthDirHasIPv6Connectivity isn't setAuthorities (directory and bridge) set up outgoing IPv6 connections
even when AuthDirHasIPv6Connectivity is 0.
This is because we end up in dirserv_single_reachability_test() from
routerlist_descriptors_added() when loading descriptors ...Authorities (directory and bridge) set up outgoing IPv6 connections
even when AuthDirHasIPv6Connectivity is 0.
This is because we end up in dirserv_single_reachability_test() from
routerlist_descriptors_added() when loading descriptors from disk at
startup.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6878Make outbound DNS requests honor IPv6 OutboundBindAddress2020-06-27T14:05:39ZLinus Nordberglinus@torproject.orgMake outbound DNS requests honor IPv6 OutboundBindAddressThe OutboundBindAddress affects what IPv4 address outgoing DNS requests bind to.
This should be extended to IPv6 addresses using the new (unreleased as of now) OutboundBindAddress [IPv6] option.The OutboundBindAddress affects what IPv4 address outgoing DNS requests bind to.
This should be extended to IPv6 addresses using the new (unreleased as of now) OutboundBindAddress [IPv6] option.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6876Add config option OutboundBindAddressIPv62020-06-27T14:05:39ZLinus Nordberglinus@torproject.orgAdd config option OutboundBindAddressIPv6We need a way to specify an outbound IPv6 address.
Either we add OutboundBindAddressIPv6 or we start parsing
OutboundBindAddress when we read configuration and store two outbound
addresses, one for each supported address family.
I have...We need a way to specify an outbound IPv6 address.
Either we add OutboundBindAddressIPv6 or we start parsing
OutboundBindAddress when we read configuration and store two outbound
addresses, one for each supported address family.
I have implemented the OutboundBindAddressIPv6 alternative (because it
was easy). Let me know if we prefer the other one.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6773DirServer lines should take more than one "orport="2020-06-27T14:05:47ZLinus Nordberglinus@torproject.orgDirServer lines should take more than one "orport="In order for clients and relays to be able to contact an authority
server over IPv6 we should expand the DirServer line to accept more
than one OR port.
Do we prefer "orport=ADDR0,ADDR1,..." or "orport=ADDR0 orport=ADDR1 ..."?
Or perhap...In order for clients and relays to be able to contact an authority
server over IPv6 we should expand the DirServer line to accept more
than one OR port.
Do we prefer "orport=ADDR0,ADDR1,..." or "orport=ADDR0 orport=ADDR1 ..."?
Or perhaps something completely different?
Note that an ADDR will be IP-ADDRESS ":" PORT-NUMBER rather than
todays PORT-NUMBER..
We need to
- add field(s) to trusted_dir_server_t
- fix the parsing in parse_dir_server_line(), probably by calling tor_addr_port_lookup().
We also need legacy/trac#6772 (Fall back to alternative OR port if the current
fails) to be implemented for this to be useful, f.ex. in
directory_post_to_dirservers().Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6772Fall back to alternative OR or Dir port if the current fails2020-07-24T13:43:34ZLinus Nordberglinus@torproject.orgFall back to alternative OR or Dir port if the current failsWhen a client (or relay, when that time comes(*)) fails to connect to
an OR port it should try using another OR port for the relay it's
trying to connect to, if there is one.
(*) relay to relay as well as relay to authority connectionsWhen a client (or relay, when that time comes(*)) fails to connect to
an OR port it should try using another OR port for the relay it's
trying to connect to, if there is one.
(*) relay to relay as well as relay to authority connectionsTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6771Change AuthDirPublishIPv6 (default: 0) somehow2020-06-27T14:05:47ZLinus Nordberglinus@torproject.orgChange AuthDirPublishIPv6 (default: 0) somehowThe config option AuthDirPublishIPv6 is a BOOL defaulting to 0. When
not set, auths don't publish "a" lines, they don't even put "a" lines
in votes.
The option came up when we thought we needed a way to make Tonga stop
this IPv6 thing b...The config option AuthDirPublishIPv6 is a BOOL defaulting to 0. When
not set, auths don't publish "a" lines, they don't even put "a" lines
in votes.
The option came up when we thought we needed a way to make Tonga stop
this IPv6 thing before the world falls apart without having to install
another version of tor. Is this a proper precaution?
If we want this option for some testing period it's a temporary option
and we should either document it as such in the man page and the
release notes or maybe remove it from the man pages alltogether.
If we trust our new code enough we could either keep the option and
let it default to 1 or just remove the option.
I no longer think that we will break existing functionality by
including "a" lines in consensus. I'd like to see "a" lines in
consensus as soon as possible but I'd like them to point at actual
working IPv6 OR ports. I suggest we remove AuthDirPublishIPv6 and let
AuthDirHasIPv6Connectivity (default: 0) decide whether an authority
votes on "a" lines or not.
This will make the number of dir auths voting for "a" lines low to
begin with but that won't stop "a" lines from going into consensus --
we don't have a floor on how many votes an "a" line needs and a vote
not containing an "a" line doesn't count as a negative vote.Tor: 0.2.4.x-finalhttps://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/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/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/6621Authorities shouldn't set Running unless all advertised OR ports are reachable2020-06-27T14:05:53ZLinus Nordberglinus@torproject.orgAuthorities shouldn't set Running unless all advertised OR ports are reachableProp 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I...Prop 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I suggest we fix that but have auths not on IPv6
(AuthDirHasIPv6Connectivity == 0) not take IPv6 reachability into
account.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6598Update dir-spec with "a" lines2020-06-27T14:05:54ZLinus Nordberglinus@torproject.orgUpdate dir-spec with "a" linesProposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Proposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6551Hidden services IPV6 address2020-06-27T14:05:55ZTracHidden services IPV6 addressohai all
First ticket. I tried to setup a hidden service using an ipv6 rather than an ipv4, in torrc:
```
#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 <IPV6>:80
```
After restarting tor I get the following error...ohai all
First ticket. I tried to setup a hidden service using an ipv6 rather than an ipv4, in torrc:
```
#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 <IPV6>:80
```
After restarting tor I get the following error:
```
Checking if tor configuration is valid [notice] Tor v0.2.3.19-rc (git-adf14e42194ebfb7) running on Linux. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning [notice] Read configuration file "/etc/tor/torrc". [warn] Unparseable address in hidden service port configuration. [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details. [err] Reading config failed--see warnings above.
```
It appears this does not work with IPv6. feature request :D.
**Trac**:
**Username**: cantorTor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6423Adding, removing or changing an IPv6 OR port isn't a cosmetic change2020-06-27T14:06:01ZLinus Nordberglinus@torproject.orgAdding, removing or changing an IPv6 OR port isn't a cosmetic changerouter_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.router_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6364Make sure the NETINFO cells include and use IPv6 addresses correctly2020-06-27T14:06:03ZLinus Nordberglinus@torproject.orgMake sure the NETINFO cells include and use IPv6 addresses correctlyTor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6027Directory authorities on IPv62020-06-27T14:06:16ZLinus Nordberglinus@torproject.orgDirectory authorities on IPv6Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in legacy/trac#4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in legacy/trac#4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6026Relays don't realise that their IPv6 OR port has changed2020-06-27T14:06:17ZLinus Nordberglinus@torproject.orgRelays don't realise that their IPv6 OR port has changedretry_all_listeners() needs fixing, see legacy/trac#4847 for more info.retry_all_listeners() needs fixing, see legacy/trac#4847 for more info.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5974Add configuration option for indicating if a directory authority is on IPv6 o...2020-06-27T14:06:18ZLinus Nordberglinus@torproject.orgAdd configuration option for indicating if a directory authority is on IPv6 or notBackground from legacy/trac#5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have ...Background from legacy/trac#5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect this.
This should be an option for authorities only for use until we have
good automatic detection of IPv6 connectivity.
The idea is that an authority with this option set to 0 will emit "a"
lines with IPv6 relay addresses without performing reachability tests.
The reasoning behind it is that relays on IPv6 shouldn't be punished
by directory authorities not on IPv6.
Regarding its default value, I think that 'auto' would be a good
default. Once we have automatic detection in place, leaving this
option out will make no difference. In the meantime 'auto' will turn
into '0' and authorities will by default let "a" lines through.
Regarding automatic detection, I wonder how we can do that without
leaking information. Is it possible? If not, how much can we leak?
Should we add more config option(s) for enabling more leaky strategies?Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org