Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-06-17T16:24:10Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23819Support IPv6 link-local interface addresses2022-06-17T16:24:10ZTracSupport IPv6 link-local interface addressesThis is either a **bug** or a **documentation defect** (didn't dive into the code yet).
Standard routing with ipv6 happens with link-local as next hop.
Hence, for the sake of making a transparent proxy for VMs, I am trying to specify a...This is either a **bug** or a **documentation defect** (didn't dive into the code yet).
Standard routing with ipv6 happens with link-local as next hop.
Hence, for the sake of making a transparent proxy for VMs, I am trying to specify a **TransPort** with the link-local of my bridge.
The standard way of specifying that is: [fe80::xxxx:xxxx:xxxx:xxxx%iface]
Tor parses correctly this ipv6 address (removing iface) but fails to bind.
To reproduce:
`$cat /etc/tor/torrc:`
(...)
`TransPort fe80::1c9a:c3ff:fec8:7768%vnet0:9040`
(...)
`$ ifconfig vnet0`
`vnet0 Link encap:Ethernet HWaddr 1e:9a:c3:c8:77:68`
` inet6: fe80::1c9a:c3ff:fec8:7768/64 c9a:c3ff:fec8:7768/64 Scope:Link`
As you can see, I have a vnet0. It has the link-local address that is specified as TransPort.
Now let's start tor:
`$ sudo tor`
`Oct 10 21:34:28.384 [notice] Tor 0.2.9.11 (git-aa8950022562be76) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.`
(...)
`Oct 10 21:34:28.385 [notice] You configured a non-loopback address '[fe80::1c9a:c3ff:fec8:7768]:9040' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.`
(...)
`Oct 10 21:34:28.386 [notice] Opening Transparent pf/netfilter listener on [fe80::1c9a:c3ff:fec8:7768]:9040`
`Oct 10 21:34:28.386 [warn] Could not bind to fe80::1[c9a:c3ff:fec8:7768:9040 c9a:c3ff:fec8:7768:9040]: Invalid argument`
As you can see, it is correctly striping the **%vnet0** and reading my link-local address from the /etc/tor/torrc
It then tries to open the "pf/netfilter" and fails to bind, and says "invalid argument"!
Indeed, binding a link-local ipv6 address needs one more argument in the syscall to bind: the interface!
**Other tests:**
Trying with fancy notations like
TransPort [fe80::1c9a:c3ff:fec8:7768]%vnet0:9040
fails at parsing.
Trying with a global address (with ipV6 you can just add addresses to the interface) works but opens other headaches such as having to advertise a different router address to the clients.
**Conclusion**, this is either:
* **(bug)** the implementation of the "interface" parameter when binding link-local addresses is missing or failing.
or
* **(documentation)** it works and it is a documentation defect since nowhere we can find how to bind a link-local ipv6 address or even a working example.
**Additional:** there could be the exact same bug/missing documentation in other places where you can specify an ipv6 address.
**Trac**:
**Username**: Zakharhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23818Make v2 and v3 single onion services retry all failed intro and rend connecti...2020-06-27T13:55:20ZteorMake v2 and v3 single onion services retry all failed intro and rend connections with a 3-hop pathThis makes a single onion service connect via an entry that it can reach when connections fail.This makes a single onion service connect via an entry that it can reach when connections fail.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23759Refactor common code out of setup_introduce1_data and intro point functions2021-09-16T14:31:39ZteorRefactor common code out of setup_introduce1_data and intro point functionsDuring legacy/trac#23577, we discovered that there's a lot of code in setup_introduce1_data() that's duplicated in service_intro_point_new() and hs_desc_lspec_to_trunnel().
In legacy/trac#23576, we removed the duplication across setup_i...During legacy/trac#23577, we discovered that there's a lot of code in setup_introduce1_data() that's duplicated in service_intro_point_new() and hs_desc_lspec_to_trunnel().
In legacy/trac#23576, we removed the duplication across setup_introduce1_data() and service_intro_point_new(), creating node_get_link_specifier_smartlist().
So we should clean that up at some point, but it's complicated, because the intro point functions use hs_desc_link_specifier_t. (See legacy/trac#22781)
Edit: update after legacy/trac#23576.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23589Stop assuming that every extend_info contains an IPv4 address in get_lspecs_f...2020-06-27T13:55:32ZteorStop assuming that every extend_info contains an IPv4 address in get_lspecs_from_extend_info()addr can be an IPv6 addressaddr can be an IPv6 addressTor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23588Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_f...2020-06-27T13:55:33ZteorWrite fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()Currently, the address choice logic is:
* if we have an IPv6 address and can reach the ls IPv6 address, and prefer IPv6, use it
* if we have an IPv4 address and can reach the ls IPv4 address, use it
But it needs to be:
* if we have both...Currently, the address choice logic is:
* if we have an IPv6 address and can reach the ls IPv6 address, and prefer IPv6, use it
* if we have an IPv4 address and can reach the ls IPv4 address, use it
But it needs to be:
* if we have both addresses and can reach both, then use whatever we prefer
* if we have one address and can reach it, use it
This doesn't matter until clients put IPv6 addresses in the link specifier.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23577Add rendezvous point IPv6 address to client introduce cells2020-06-27T13:55:33ZteorAdd 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/tpo/core/tor/-/issues/23576Make service_intro_point_new() take a node instead of an extend_info2020-06-27T13:55:34ZteorMake service_intro_point_new() take a node instead of an extend_infoservice_intro_point_new() and hs_desc_link_specifier_new() need to take a node_t, so they can fill it in with IPv4 and IPv6 addresses.service_intro_point_new() and hs_desc_link_specifier_new() need to take a node_t, so they can fill it in with IPv4 and IPv6 addresses.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23507Handle unreachable addresses on v3 single onion services by using a 3 hop path2020-06-27T13:55:39ZteorHandle unreachable addresses on v3 single onion services by using a 3 hop pathHere is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop...Here is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.
Here are the steps:
0. The service chooses and connects to the intro point (possibly using a 3-hop path if it is a single onion service and can't reach it directly)
1. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
2. If the link specifier has a reachable address, and the service is not a single onion service, a Tor2web client (currently v2 only) can use it to make a direct connection to the intro point
3. Otherwise, the client connects over a 3-hop path via one of its reachable entry nodes
The process for client rendezvous is similar, but if the client knows that the service is a single onion service, it *must* connect to the rend point using a 3-hop path. (Again, this only matters for Tor2web, which is v2 only).Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23502v3 Onion Services: don't make IPv4 mandatory because one day we'll have IPv6 ...2022-06-17T14:20:27ZDavid 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.https://gitlab.torproject.org/tpo/core/tor/-/issues/23493IPv6 v3 Onion Services support2020-06-27T13:55:40ZteorIPv6 v3 Onion Services supportUsing the latest tor master (3092c8bb3e) and the latest chutney (d3cec81):
```
chutney/tools/test-network.sh --flavour single-onion-v3-ipv6
```
Fails and logs a bug message:
```
Sep 13 12:21:43.845 [notice] Tor has successfully opened a...Using the latest tor master (3092c8bb3e) and the latest chutney (d3cec81):
```
chutney/tools/test-network.sh --flavour single-onion-v3-ipv6
```
Fails and logs a bug message:
```
Sep 13 12:21:43.845 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 13 12:21:43.845 [notice] Bootstrapped 100%: Done
Sep 13 12:21:44.798 [info] set_rotation_time: Next descriptor rotation time set to 2017-09-13 12:24:00 for ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid
Sep 13 12:21:44.802 [info] build_descriptors_for_new_service: Hidden service ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid has just started. Both descriptors built. Now scheduled for upload.
Sep 13 12:21:44.803 [info] extend_info_from_node: Including Ed25519 ID for $DB859DF7648323E1766C122E077DA476720A0FB0~test000a at 127.0.0.1
Sep 13 12:21:44.803 [warn] tor_bug_occurred_: Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: Non-fatal assertion !(!ls) failed in service_intro_point_new at src/or/hs_service.c:403. Stack trace: (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: 0 tor 0x000000010d938989 log_backtrace + 73 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: 1 tor 0x000000010d9a6614 tor_bug_occurred_ + 452 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: 2 tor 0x000000010d74b671 hs_service_run_scheduled_events + 12817 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: 3 tor 0x000000010d7754fe hs_service_callback + 62 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 4 tor 0x000000010d7f024f periodic_event_dispatch + 271 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 5 libevent-2.1.6.dylib 0x000000010e4a90bf event_process_active_single_queue + 371 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 6 libevent-2.1.6.dylib 0x000000010e4a6699 event_base_loop + 1170 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 7 tor 0x000000010d765696 do_main_loop + 2422 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 8 tor 0x000000010d76e432 tor_main + 546 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 9 tor 0x000000010d4236eb main + 27 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug: 10 libdyld.dylib 0x00007fff8edaf235 start + 1 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [info] pick_needed_intro_points: Unable to find a suitable node to be an introduction point for service ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid.
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23082tor_addr_parse is overly permissive2020-06-27T13:56:00ZDavid Fifielddcf@torproject.orgtor_addr_parse is overly permissivetor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → ...tor_addr_parse allows these surprising address formats:
* `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
* `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
* `[11:22::33:44` (IPv6 with left square bracket only) → 11:22::33:4
* `11:22::33:44:` (IPv6 with trailing colon) → 11:22::33:44Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/22781hs: Unify link specifier API/ABI2020-06-27T13:56:16ZDavid Gouletdgoulet@torproject.orghs: Unify link specifier API/ABIIn `hs_descriptor.{c|h}`, link specifiers are used to encode the introduction points in the descriptor. The decoded version is represented by the `hs_desc_link_specifier_t` object which is used to build a trunnel object that is then base...In `hs_descriptor.{c|h}`, link specifiers are used to encode the introduction points in the descriptor. The decoded version is represented by the `hs_desc_link_specifier_t` object which is used to build a trunnel object that is then base64 encoded and put in the descriptor.
With the service and client implementation of prop224, link specifiers are also used in the INTRODUCE1 cell. Client will encode them in the cell and service decodes them (INTRODUCE2 cell).
This ticket is to unify the link specifier API/ABI used between cell and descriptor for both encoding and decoding in order to avoid code duplication.
Furthermore, future work could expend this to the `EXTEND2` cell that also requires link specifiers (`extend_cell_from_extend2_cell_body()` and `extend_cell_format()`.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22697Tor should mandatory require brackets around ipv6 address2020-07-28T03:41:11ZtoralfTor should mandatory require brackets around ipv6 addressStem and Tor do differ about validating an ipv6 address :
```
ValueError: '2a00:1450:4001:0058::7/16' isn't a wildcard, IPv4, or IPv6 address: reject6 2a00:1450:4001:0058::7/16:443
```
The same term is accepted by Tor (within torrc).
ma...Stem and Tor do differ about validating an ipv6 address :
```
ValueError: '2a00:1450:4001:0058::7/16' isn't a wildcard, IPv4, or IPv6 address: reject6 2a00:1450:4001:0058::7/16:443
```
The same term is accepted by Tor (within torrc).
maybe Tor should be more strict too ?
A short talk with atagar on IRC yielded into this bug report.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22469tor should probably reject "0x00" in port range specifications2021-10-04T19:22:56Ztoralftor should probably reject "0x00" in port range specificationssomething like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.something like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.https://gitlab.torproject.org/tpo/core/tor/-/issues/21902evdns adds default DNS servers, but chutney wants a consistent environment2020-07-28T02:57:49Zteorevdns adds default DNS servers, but chutney wants a consistent environmentWhen we test tor exits using chutney, we want a consistent network environment, so that tests pass or fail reliably.
This means that we want to be able to configure exits with no DNS servers, and have them only connect to IP addresses.
...When we test tor exits using chutney, we want a consistent network environment, so that tests pass or fail reliably.
This means that we want to be able to configure exits with no DNS servers, and have them only connect to IP addresses.
But evdns adds default name server(s) in some circumstances (for example, 127.0.0.1:53.)
This default could also be an issue on an IPv6-only system, where we'd want [::1]:53. (Yes, some IPv6-only systems don't even have an IPv4 localhost!)
This is also broken because of the empty/missing resolv.conf behaviour in legacy/trac#21900.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21899Address setting ignoring IPv62020-06-27T13:56:53ZTracAddress setting ignoring IPv6According to the torrc man page:
"Address: The IP address or fully qualified domain name of this server (e.g. moria.mit.edu)."
In torrc, set the Address to an IPv6 address and port using standard notation:
Address [1234:5678::01:1234]...According to the torrc man page:
"Address: The IP address or fully qualified domain name of this server (e.g. moria.mit.edu)."
In torrc, set the Address to an IPv6 address and port using standard notation:
Address [1234:5678::01:1234]
----
The tor server starts up, and doesn't appear to give any relevant warnings, but log output suggests tor is ignoring the address setting and guessing anyway.
Apr 09 15:50:52.000 [notice] Guessed our IP address as 1.2.3.4 (source: 5.6.7.8).
This server is configured only with IPv6 settings for tor, and the goal is to have it ignore any IPv4 addresses present on the host, so this behavior is undesirable.
**Trac**:
**Username**: ItsNannerpussTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21524private:* contains valid IPv6 addresses2020-07-26T15:06:24Zteorprivate:* contains valid IPv6 addressesChutney's IPv6 exits trigger this error:
`IPv4 address 'private:*' with accept6/reject6 field type in exit policy. Ignoring, but continuing to parse rules. (Use accept/reject with IPv4 addresses.)`
because they say in their torrc:
```
ac...Chutney's IPv6 exits trigger this error:
`IPv4 address 'private:*' with accept6/reject6 field type in exit policy. Ignoring, but continuing to parse rules. (Use accept/reject with IPv4 addresses.)`
because they say in their torrc:
```
accept6 private:*
```
We should make this work.Tor: unspecifiedcchttps://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/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/21493When reachable addresses change, mark connections using those addresses2020-06-27T13:57:10ZteorWhen reachable addresses change, mark connections using those addressesWhen a client's reachable addresses change, we should:
* close connections that are on newly unreachable addresses,
* mark connections that are on non-preferred connections as "not for new streams".
This implements user intent faster th...When a client's reachable addresses change, we should:
* close connections that are on newly unreachable addresses,
* mark connections that are on non-preferred connections as "not for new streams".
This implements user intent faster than the current code (which essentially does nothing, and waits for old unreachable connections to die naturally, and new reachable connections to replace them).Tor: 0.3.0.x-final