Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:27:40Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21310Exits should tell clients when they are connecting to an IPv6-only hostname2020-06-13T15:27:40ZteorExits should tell clients when they are connecting to an IPv6-only hostnameWhen #21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyWhen #21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21311Exits should resolve IPv6 addresses, regardless of IPv6Exit2020-06-13T15:27:40ZteorExits should resolve IPv6 addresses, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26664When an exit tells a client about an IPv6-only hostname, the client should ch...2020-06-13T15:27:40ZteorWhen an exit tells a client about an IPv6-only hostname, the client should choose another IPv6 exitWhen #21311 and #21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that leads to tagging attacks.When #21311 and #21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that leads to tagging attacks.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26646add support for multiple OutboundBindAddressExit IP(ranges)2020-06-13T15:27:37Znusenuadd support for multiple OutboundBindAddressExit IP(ranges)tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and ...tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.
The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.
Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.
With IPv6 address space availability this can take a long time
with IPv4 it will be limited.
This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.
This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.
Instead of doing it on the circuit level you could do it
based on time. Change the exit IP every 5 minutes (but
do _not_ change the exit IPs for _existing_ circuits even if they
live longer than 5 minutes).
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-06-13T15:26:54ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of #15518.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26436Check uses of CMP_SEMANTIC for IP addresses2020-06-13T15:26:53ZteorCheck uses of CMP_SEMANTIC for IP addressesFrom #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 i...From #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.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26303IPv6-Flagging of Relay not accurate2020-06-13T15:26:25ZTracIPv6-Flagging of Relay not accurateOur Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.
All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Po...Our Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.
All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Ports are open for connections via IPv6.
**Trac**:
**Username**: ruebezahlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25784Misleading error message when asking for IPv6 in a network with no IPv6-capab...2020-06-13T15:24:23ZpastlyMisleading error message when asking for IPv6 in a network with no IPv6-capable exitsI created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an e...I created a small test Tor network. 3 authorities, 7 relays, 3 exits. Great.
I didn't set `IPv6Exit 1` on any of the exits.
I had a client try to request `::1` over this Tor network on a hand crafted circuit (it makes sense to ask an exit to connect to localhost when this is all local ... trust me). I got the following confusing error message on the client.
> [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
I think it's important to point out (again) that I was hand crafting these circuits and was not considering IPv6 support. That said, I don't know what Tor would do if I let it make the circuit for me and it couldn't find an IPv6-supporting exit.
As you can see, I'm talking myself out of this being a bug and it just being me screwing things up for myself. I was encouraged to make a ticket though, so here we are.
If rewriting the error message is the solution, maybe after fixing the "fulfil" typo, we should add "It's also possible we couldn't find any exits supporting the IP version you want to use"
I'm picking 0.3.5.x-final just because I've been told you have to pick a milestone or else your tickets generally fall through the cracks. :)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25295Torsocks only accepts IPv4 replies but Tor prefers IPv6Automap by default2020-06-13T15:22:11ZTracTorsocks only accepts IPv4 replies but Tor prefers IPv6Automap by defaultAt the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer...At the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:681)` when tor replies with an IPv6 address, which it does every single time for mapaddress .exit entries for me.
**Trac**:
**Username**: fuzzyTewTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25245Crash in assert_connection_ok when changing Exit options2020-06-13T15:22:00ZtoralfCrash 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/legacy/trac/-/issues/252130.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)...2020-06-13T15:21:53ZTrac0.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed.Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the rem...Running 2 tor relays, whilst restarting Tor going from 0.3.3.1-alpha-dev to 0.3.3.2-alpha one of the two nodes gave the following error for 3 other relays, being: Rea, fury and lowtideceviche
It's just running for 2 hours or so, the remaining functionality seems OK.
Feb 11 20:01:04 tornode1 Tor[23044]: tor_bug_occurred_(): Bug: ../src/or/policies.c:1008: fascist_firewall_choose_address_node: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed. (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed in fascist_firewall_choose_address_node at ../src/or/policies.c:1008. Stack trace: (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(log_backtrace+0x44) [0x55a3a4d5bde4] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55a3a4d77479] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(fascist_firewall_choose_address_node+0x182) [0x55a3a4c47682] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(extend_info_from_node+0x12f) [0x55a3a4caaa7f] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(+0xed980) [0x55a3a4cc0980] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x261) [0x55a3a4cc0eb1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a8) [0x55a3a4ce2808] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(do_main_loop+0x399) [0x55a3a4c278f9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_run_main+0x275) [0x55a3a4c28f25] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55a3a4c2236a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(main+0x19) [0x55a3a4c220d9] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6eb6b052b1] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Bug: /usr/bin/tor(_start+0x2a) [0x55a3a4c2212a] (on Tor 0.3.3.2-alpha )
Feb 11 20:01:04 tornode1 Tor[23044]: Could not choose valid address for Rea
Feb 11 20:01:04 tornode1 Tor[23044]: Could not make a one-hop connection to $8DCB8A8CD726EBCE5CCC90581EB7A695D6B09904. Discarding this circuit.
**Trac**:
**Username**: sjcjonkerTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25211Tor fails to resolve ipv6.google.com2020-06-13T15:21:52Zrl1987Tor fails to resolve ipv6.google.commacOS 11.13.2, Tor Browser 7.5, Tor 1df701c082761775d311a966a222bca116afc3c2
Trying to access https://ipv6.google.com tends to fail with following messages in the log:
```
Feb 11 17:44:43.000 [info] connection_ap_process_end_not_open: ...macOS 11.13.2, Tor Browser 7.5, Tor 1df701c082761775d311a966a222bca116afc3c2
Trying to access https://ipv6.google.com tends to fail with following messages in the log:
```
Feb 11 17:44:43.000 [info] connection_ap_process_end_not_open: Address '[scrubbed]' refused due to 'resolve failed'. Considering retrying.
Feb 11 17:44:43.000 [info] client_dns_incr_failures: Address [scrubbed] now has 3 resolve failures.
Feb 11 17:44:43.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
```https://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/25036Tor 0.3.2 rejects connections to raw ipv6 addresses2020-06-13T15:21:14ZpastlyTor 0.3.2 rejects connections to raw ipv6 addressesOS X 10.11.6, Tor Browser 7.5
I have to configure TB to use a socks5 proxy to reach the internet (I predict this is unrelated). I disabled safe logging.
Attempting to go to https://[2a00:1450:401b:800::200e]/ (google) produces the foll...OS X 10.11.6, Tor Browser 7.5
I have to configure TB to use a socks5 proxy to reach the internet (I predict this is unrelated). I disabled safe logging.
Attempting to go to https://[2a00:1450:401b:800::200e]/ (google) produces the following Tor logs.
```
1/26/18, 14:51:25.600 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop
1/26/18, 14:51:48.700 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
1/26/18, 14:51:50.000 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
1/26/18, 14:51:50.000 [NOTICE] Bootstrapped 100%: Done
1/26/18, 14:51:50.900 [NOTICE] New control connection opened from 127.0.0.1.
1/26/18, 14:51:51.000 [NOTICE] New control connection opened from 127.0.0.1.
1/26/18, 14:54:06.900 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:54:06.900 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:55:38.200 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
1/26/18, 14:55:38.200 [WARN] Your application (using socks5 to port 443) gave Tor a malformed hostname: "2a00:1450:401b:800::200e". Rejecting the connection.
```
https://ipv6.google.com works with every 6th circuit. I'm sure this is unrelated and has to do with exits half supporing ipv6 or something.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23577Add rendezvous point IPv6 address to client introduce cells2020-06-13T15:20:29ZteorAdd rendezvous point IPv6 address to client introduce cellsTo provide both IPv4 and IPv6 addresses, setup_introduce1_data() needs to take a node, and we need to create a new get_lspecs_from_node() function.To provide both IPv4 and IPv6 addresses, setup_introduce1_data() needs to take a node, and we need to create a new get_lspecs_from_node() function.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24868Check a consensus parameter before activating onion service IPv6 features2020-06-13T15:20:29ZteorCheck a consensus parameter before activating onion service IPv6 featuresWe've implemented #23577, but it looks like none of the other onion service IPv6 code will be ready for 0.3.3.
(We want to do the relay IPv6 code first.)
If we merge this in 0.3.3, then services will be able to distinguish 0.3.2 and 0....We've implemented #23577, but it looks like none of the other onion service IPv6 code will be ready for 0.3.3.
(We want to do the relay IPv6 code first.)
If we merge this in 0.3.3, then services will be able to distinguish 0.3.2 and 0.3.3 (and later) clients, when the rend point is dual-stack.
Do we want to add a torrc option / consensus parameter for v3 onion service IPv6? Or are we happy with this information leak?Tor: unspecifiedteorteorhttps://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/24833DNS not reliably returning AAAA records2020-06-13T15:20:04ZTracDNS not reliably returning AAAA records**[Enhancement Request]**
(Cleaner explanation than closed ticket #24798)
I have a Tor Router set with dual stack.
DNS is done in ipv4 through (it should not matter since an ipv4 DNS can still respond to AAAA queries)
**I can't find a...**[Enhancement Request]**
(Cleaner explanation than closed ticket #24798)
I have a Tor Router set with dual stack.
DNS is done in ipv4 through (it should not matter since an ipv4 DNS can still respond to AAAA queries)
**I can't find a setting to make DNS reliably returning AAAA records**: it is sort of "random", probably depending on the exit node.
`$ uname -a`
`Linux user-pc 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux`
`$ tor --version`
`Tor version 0.2.9.11 (git-aa8950022562be76).`
(I will test 0.3.1, as recommended, next week when we have Bionic Beaver Alpha 1... to avoid having to compile with Ubuntu chaintool I'm not so familiar with... and because it has dependencies that are not in 16.04 -already tried!)
Here is the relevant tor snippet
`$ head /etc/tor/torrc`
`DNSPort 172.16.0.1:9053 IPv6Traffic`
`TransPort 172.16.0.1:9040`
`TransPort [fe80::10%vnet0]:9040`
`ClientUseIPv6 1`
`ClientPreferIPv6ORPort 1`
`ClientPreferIPv6DirPort 1`
Here is what I get from a machine connected to the router:
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; curl -g -H 'Host: ifconfig.co' http://[2001:470:28:840::cafe:d00d]; echo "dig"; dig ifconfig.co A ifconfig.co AAAA +short;`
`46.182.19.15`
`2607:5300:120:312::1:1`
`dig`
`188.113.88.193`
`$ !!`
`199.87.154.255`
`2a00:fc00:e000:b001::f4ee`
`dig`
`188.113.88.193`
`$ !!`
`5.254.112.154`
`2620:18c:0:1001::102`
`dig`
`188.113.88.193`
`2001:470:28:840::cafe:d00d`
`$ !!`
`197.231.221.211`
`2620:18c:0:1001::102`
`dig`
`188.113.88.193`
`$ !!`
`192.42.116.16`
`2604:8b40:1:3::1`
`dig`
`188.113.88.193`
`$ !!`
`185.220.101.16`
`2a03:f85:8::7`
`dig`
`188.113.88.193`
`2001:470:28:840::cafe:d00d`
_(changing exit between each repetition with a NEWNYM command)_
So, as you can see, both the ipv4 an the ipv6 stack work (first 2 curls of the command line), no issue with that fortunately!
For ipv6 I have to force the ipv6 address since the DNS query not always returns AAAA responses.
Depending on the exit host, we get AAAA responses... or not!
**Question:** how to make AAAA responses reliable?
''P.S.: from teor's response in my initial ill-worded ticket, I don't think it is relevant to add 'IPv6Traffic' to TransPort. Indeed, when you bind the TransPort to an ipv4 address you can't sen ipv6 there, and when you bind to an ipv6 address, it is already for ipv6.
Even more, you can't do that: tor-0.2.9 rightfully complaining when you add that to TransPort, whereas it is pleased (but has no effect!) when you specify the option for DNSPort''
_P.S.2: You might have noticed the [fe80::10%vnet0] in my torrc, this is not a bug, I am using my patched version that accepts binding to link-local ipv6 addresses. #23819_
**Trac**:
**Username**: ZakharTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24798Enforce ipv4 + ipv6 capable exit2020-06-13T15:19:48ZTracEnforce ipv4 + ipv6 capable exit**[Enhancement Request]**
_(unless I missed something in the configurations and options!)_
While trying to add ipv6 capability to my Tor router, I noticed a limitation.
There does not seem to be a parameter in the configuration to ens...**[Enhancement Request]**
_(unless I missed something in the configurations and options!)_
While trying to add ipv6 capability to my Tor router, I noticed a limitation.
There does not seem to be a parameter in the configuration to ensure that the selected exit node is ipv6 capable... which could be unfortunate if the client really needs ipv6!
Did I miss such a parameter in the configuration?
So here is some test output. This is done from a machine connected to my "Tor router" which is transparently (for the client) routing all TCP traffic to Tor, routing DNS through Tor, and discards the rest.
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short`
`185.107.81.234`
`216.58.198.206`
`2a00:1450:4007:809::200e`
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short`
`216.218.222.14`
`172.217.15.110`
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short`
`185.220.101.13`
`172.217.19.206`
`2a00:1450:400e:805::200e`
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short`
`142.44.156.128`
`216.58.212.206`
`$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short`
`77.247.181.162`
`172.217.17.142`
`2a00:1450:400e:807::200e`
Between each command, I send a NEWNYM through the command port (on the router) to get a new identity.
The curl gives the ipv4 address of the exit node.
DIG tries to get both ipv4 and ipv6 addresses of a site we konw has both (google here).
As we can see, depending on our exit node we get or we don't get AAAA adresses.
(DNS is done with ipv4)
When we don't get AAAA resolution, as expected, we don't either have ipv6 connectivity.
Although this is undocumented, an educated guess is that an ipv4-only exit would never send back AAAA responses to DNS requests since it can't handle an incoming request to connect to an ipv6 host. Correct me if I'm wrong on that, as I didn't check in the code... just guessing!
This makes perfect sense and is coherent with what we can observe.
But then, __from the client point of view__, having** ipv6 connectivity is unreliable**.
From trying to understand the "path-spec", I can imagine that if the client provides an ipv6 address instead a host name when the circuit is established, it could do the trick (not tested it!). But that would not be practical at all for end-users (already with ipv4 it's bad, but ipv6 is hell!)
At worst **it can trigger errors**: since a client might cache DNS responses, when you have an ipv6 capable exit node, then a AAAA response and use ipv6, and you happen to hit MaxCircuitDirtiness and change exit, you could be sending ipv6 requests to an exit that can't handle that, resulting in hard to diagnose errors.
Hence this ticket: it would be nice to be able to have a flag (or any reliable method) __allowing to select only ipv6 capable exits__.
For example, we already have:
ClientUseIPv6
(I assume that one of the result of that is to triggers AAAA responses to DNS)
We could have:
**ClientNeedIPv6**
Or same as you can select exits by country, being able to select exits with ipv6
**ExitNodes ipv6**
(This is not as good because it becomes confusing when you add countries, since the implied operator when you supply a list of nodes is OR, and we obvisouly want AND for ipv6)
This should obviously be used with caution, and only when you really need it since it might harm anonymity by reducing the number of possible exits (same as selecting a country does!).
Should you thinks there is not yet enough ipv6 capable exits, this enhancement could be put in the roadmap at a later date.
From my tests short tests randomly changing exits, I got between around half of capable ipv6 exits... you might have a more reliable stat to decide I guess!
**Trac**:
**Username**: ZakharTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24778Mark prop#283 as Accepted2020-06-13T15:19:44ZteorMark prop#283 as AcceptedWe have merged all the spec changes and half the code, so we've definitely accepted this one.We have merged all the spec changes and half the code, so we've definitely accepted this one.Tor: 0.3.3.x-finalteorteor