Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:43:24Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31088Check IPv4 and IPv6 private addresses in descriptors2020-06-13T15:43:24ZteorCheck IPv4 and IPv6 private addresses in descriptorsTor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require...Tor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require IPv6 extends from #24403:
When relays extend:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L1253
And when clients connect:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L552Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29570Stop relays publishing descriptors containing NoListen IPv6 ORPorts2020-06-13T15:38:31Zs7rStop relays publishing descriptors containing NoListen IPv6 ORPortsFor details:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016988.html
and my reply:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016991.html
This is one rare and strange setup of using IPv6 in a w...For details:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016988.html
and my reply:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016991.html
This is one rare and strange setup of using IPv6 in a way it is not intended, but we should still make sure that:
- if ORPort [IPv6:address::x]:port **NoListen** was set in torrc, and there is no following ORPort [IPv6:address::y]:port **NoAdvertise** or [::]:port **NoAdvertise** (as in use all available IPv6 addresses) is set, warn in the log and **do not build the descriptor using the NoListen address**, since the daemon is not listening on any address from the v6 class.
- check if the logic is applied for IPv4 also, even it's impossible to experience this in IPv4 since UnreachableIPv4 doesn't exist and can't possibly exist.
Otherwise we fill the descriptor with useless data and also have the directory authorities chase green horses.
I think we have this since forever, but not marking this as a backport given the rare cases when it can occur and the state of current IPv6 adoption.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24181v3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service...2020-06-13T15:28:50Zteorv3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service EXTEND cellsProp224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/p...Prop224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689
We should either remove this from the spec, or we should:
* add a similar sentence for client descriptor lspecs
* put unrecognised lspecs in descriptors in client intro EXTEND requests
* put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requestsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26971Add rendezvous point unrecognised link specifiers to client introduce cells2020-06-13T15:28:50ZteorAdd rendezvous point unrecognised link specifiers to client introduce cellsLike #24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346Like #24181, we need to take unrecognised link specifiers from onion service descriptors, and put them in client introduce cells.
https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1346Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-13T15:21:46ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24867Do relays keep more than one canonical connection when they extend over IPv6?2020-06-13T15:20:28ZteorDo relays keep more than one canonical connection when they extend over IPv6?We should find out, and fix any issues.
The warnings would look something like #24841.We should find out, and fix any issues.
The warnings would look something like #24841.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24735Always check for the null address when calling address functions2020-06-13T15:19:28ZteorAlways check for the null address when calling address functionsThese address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.These address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24734Remove the return value of fascist_firewall_choose_address_node()2020-06-13T15:19:28ZteorRemove the return value of fascist_firewall_choose_address_node()Let's check for the null address instead.Let's check for the null address instead.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24732Remove unused IPv6 DirPort code2020-06-13T15:19:26ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24731Stop checking routerinfos for addresses when we use microdescs for circuits2020-06-13T15:19:25ZteorStop checking routerinfos for addresses when we use microdescs for circuitsDirectory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following ord...Directory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following order:
* bridge routerinfos (descriptors)
* routerstatus (consensus)
If using microdescriptors for circuits:
* microdescriptors
Otherwise:
* routerinfos (descriptors)
There is code that implements this algorithm in commits decb0636e2, 1d1c927b9a, and 4979ec3c17 of my bug23975_tree branch.
But this adds overhead to every address lookup when building circuits.
Maybe we can make it faster by:
* not parsing routerinfos or microdescs if we aren't using them for circuits, or
* putting a canonical address in node_t, updating it whenever ri, rs, or md change, and always using itTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24603Update control spec to allow decorated IPv6 addresses in reachability events2020-06-13T15:18:48ZteorUpdate control spec to allow decorated IPv6 addresses in reachability eventsWhen we add IPv6 ORPort reachability checks, we want them to report decorated addresses (with brackets) to avoid ambiguity.When we add IPv6 ORPort reachability checks, we want them to report decorated addresses (with brackets) to avoid ambiguity.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24535Document which address functions we should use, and when2020-06-13T15:18:27ZteorDocument which address functions we should use, and whennickm says that there are a lot of ways to get an address in Tor.
Let's document the functions that are left at the end of #23975, and when each of them should be used. It would be nice to have a summary, and then also details in each f...nickm says that there are a lot of ways to get an address in Tor.
Let's document the functions that are left at the end of #23975, and when each of them should be used. It would be nice to have a summary, and then also details in each function comment.
We'll need to include these functions:
* node_get_*_*port()
* *_choose_address()
* any others?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24451Put IPv6 link specifiers in client EXTEND cells2020-06-13T15:18:06ZteorPut IPv6 link specifiers in client EXTEND cellsClients should put IPv6 link specifiers in the EXTEND cells to relays they choose from directory documents.
We need to do this in the same releases as #24181, to avoid adding an v3 onion service distinguisher.Clients should put IPv6 link specifiers in the EXTEND cells to relays they choose from directory documents.
We need to do this in the same releases as #24181, to avoid adding an v3 onion service distinguisher.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24406Implement IPv6 ORPort reachability fallback2020-06-13T15:17:59ZteorImplement IPv6 ORPort reachability fallbackImplement the IPv6 ORPort reachability fallback from #24404.Implement the IPv6 ORPort reachability fallback from #24404.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24405Implement relay IPv6 extends with proposed protover2020-06-13T15:17:58ZteorImplement relay IPv6 extends with proposed protoverMake relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare t...Make relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare the protover from #24404.
Make them implement the IPv4/IPv6 Extend behviour from #24404.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24404Propose a relay protover that allows IPv6 extends2020-06-13T15:17:58ZteorPropose a relay protover that allows IPv6 extendsWrite a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may ...Write a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2020-06-13T15:17:53ZteorClients 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 #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 #15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24338DirAuths that have IPv6 addresses don't include them in their vote on themself2020-06-13T15:17:36ZTom Rittertom@ritter.vgDirAuths that have IPv6 addresses don't include them in their vote on themselfCheck out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF...Check out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF4735A19BCA1DE97281
Also strange: dannenberg votes on ReachableIPv6 but is not itself granted ReachableIPv6Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23502v3 Onion Services: don't make IPv4 mandatory because one day we'll have IPv6 ...2020-06-13T15:16:19ZDavid Gouletdgoulet@torproject.orgv3 Onion Services: don't make IPv4 mandatory because one day we'll have IPv6 only relaysRight now it is not possible to have a relay that is IPv6 *only* in the public network but one day it will.
Proposal 224 makes IPv4 mandatory for link specifiers in order for a relay to extend to it. It would be wise to NOT make it mand...Right now it is not possible to have a relay that is IPv6 *only* in the public network but one day it will.
Proposal 224 makes IPv4 mandatory for link specifiers in order for a relay to extend to it. It would be wise to NOT make it mandatory and instead make it mandatory to at least have IPv4 or IPv6.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23873Remove the return value of node_get_prim_orport()2020-06-13T15:15:56ZteorRemove the return value of node_get_prim_orport()~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null ad...~~Also, we don't clear the address and port when we fail.~~
~~This probably doesn't matter right now, but it matters as soon as we try to change node_get_prim_orport().~~
We don't check it, so let's remove it, and check for the null address instead.Tor: 0.3.4.x-final