Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-09-19T21:17:44Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19487Meek and ReachableAddresses2022-09-19T21:17:44ZcypherpunksMeek and ReachableAddressesThis came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `Fasci...This came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `FascistFirewall`. While the ports they can reach might be set correctly, when using `meek` `tor` sees the destination address as a fake destination. You end up with a log that looks like this:
```
NOTICE: Bridge at '0.0.2.0:1' isn't reachable by our firewall policy. Skipping.
```
This happens because they haven't defined `0.0.2.0:1` as being a reachable address, while in reality it's using (most likely) port 443 on some CDN, which might actually be defined reachable.
Maybe not a common issue but an interesting edge case that may be clarified, avoided, or documented somewhere.https://gitlab.torproject.org/tpo/core/tor/-/issues/34200Refactor tor's circuit path node selection checks2022-07-11T12:31:51ZteorRefactor tor's circuit path node selection checksIn legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In legacy/trac#33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32954Stop public authorities specifying an internal address for their IPv6 ORPort2022-06-24T14:53:56ZteorStop public authorities specifying an internal address for their IPv6 ORPortWhen we implement `Address [IPv6]` in legacy/trac#30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.When we implement `Address [IPv6]` in legacy/trac#30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.https://gitlab.torproject.org/tpo/core/tor/-/issues/23824Make IPv6-only bridges work2022-06-24T14:24:45ZteorMake IPv6-only bridges workThis needs bridge guards (#7144 - so the bridge can connect via a dual-stack bridge guard to whatever guard the client has selected), and it needs IPv6 bridges to work in general (#4847).This needs bridge guards (#7144 - so the bridge can connect via a dual-stack bridge guard to whatever guard the client has selected), and it needs IPv6 bridges to work in general (#4847).https://gitlab.torproject.org/tpo/core/tor/-/issues/32314Can't connect to literal IPv6 address containing double colon2022-06-22T15:31:59ZTracCan't connect to literal IPv6 address containing double colonWhen an application wants to use Tor's SOCKS port to connect to a known IPv6 address, it has a couple of options:
- It can specify a 16-byte binary address using address type 4.
- It can specify the address as an ASCII string using add...When an application wants to use Tor's SOCKS port to connect to a known IPv6 address, it has a couple of options:
- It can specify a 16-byte binary address using address type 4.
- It can specify the address as an ASCII string using address type 3.
If the address is specified as a string, Tor accepts IPv6 addresses either with or without brackets. For example, Tor will accept either "2a01:4f8:fff0:4f:266:37ff:fe2c:5d19" or "[2a01:4f8:fff0:4f:266:37ff:fe2c:5d19]".
However, if the address is abbreviated using double-colon notation, it only works if enclosed in brackets: "[2a00:1450:4001:800::200e]" works, but "2a00:1450:4001:800::200e" does not. On the other hand, the unabbreviated form "2a00:1450:4001:800:0:0:0:200e" does work.
The problem appears to be:
- The destination is transmitted to the exit relay as a string of the form "<hostname>:<port>".
- The exit relay tries to parse this string by calling the function tor_addr_port_split.
- The string "2a00:1450:4001:800::200e:80" is a valid IPv6 literal, so tor_addr_port_split interprets it as an address with no port number.
- The relay refuses to connect to an address with no port number.
Note that if the application uses the binary form (address type 4), this is internally converted into a string enclosed in brackets. However, it seems to be more common for applications to use the ASCII form, without brackets. For example, if you try to visit http://[2a00:1450:4001:800::200e]/ in Tor Browser, it will fail, whereas http://[2a01:4f8:fff0:4f:266:37ff:fe2c:5d19]/ succeeds.
So there are a few ways this could be fixed:
(a) applications could be changed to use either the binary form or wrap the address in brackets;
(b) the Tor proxy could automatically add brackets around IPv6 addresses;
(c) the exit relay could be smarter about parsing IPv6 addresses.
It seems to me that (b) would be the most sensible option, but it might be reasonable to do (c) as well.
In the long term, I think it'd be wise to deprecate the use of IPv6 addresses without brackets in RELAY_BEGIN, as well as any other places where tor_addr_port_split is used, because it's just confusing.
**Trac**:
**Username**: liberathttps://gitlab.torproject.org/tpo/core/tor/-/issues/33617Add a BandwidthStatistics option and consensus parameter2022-06-17T19:10:47ZteorAdd a BandwidthStatistics option and consensus parameterStage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthSt...Stage 1:
We propose adding a new BandwidthStatistics torrc option, which activates reporting of all the bandwidth statistics. At the moment, all statistics are controlled by ExtraInfoStatistics, but we propose using the new BandwidthStatistics option specifically for the bandwidth statistics.
The default value of this option should be 1. (The existing bandwidth statistics are reported by default.)
The new option should have a manual page entry, and test_parseconf.sh tests in src/test/conf_examples.
Stage 2:
Add a BandwidthStatistics consensus paramter.
Change the default value of the BandwidthStatistics option to "auto". If the value is "auto", use the value of the consensus parameter. If the consensus parameter is not set, use "1".
Update the manual page to describe the new consensus parameter.
See the proposal:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n298MrSquancheeMrSquancheehttps://gitlab.torproject.org/tpo/core/tor/-/issues/17230Local DNS resolver will not resolve AAAA records with fc00::/8 prefixes.2022-06-17T18:57:41ZTracLocal DNS resolver will not resolve AAAA records with fc00::/8 prefixes.When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, w...When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, which are typically specified using h.domain.tld addresses.
[Example](http://pastie.org/private/3ote0ky6lfzmkp4tcnwfbg)
**Trac**:
**Username**: JacobHennerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24777Make relays try IPv6 ORPorts for directory uploads and downloads2022-06-17T18:42:58ZteorMake relays try IPv6 ORPorts for directory uploads and downloadsUsing IPv6 ORPorts will make relay behaviour consistent with future client behaviour.
The only difference is that relays will also use IPv4 DirPorts, but clients will not.
Relays should try to upload descriptors using IPv4 and IPv6 as ...Using IPv6 ORPorts will make relay behaviour consistent with future client behaviour.
The only difference is that relays will also use IPv4 DirPorts, but clients will not.
Relays should try to upload descriptors using IPv4 and IPv6 as well, to detect authority connectivity issues.https://gitlab.torproject.org/tpo/core/tor/-/issues/23975Make node_get_pref_ipv6_orport() check addresses in the right order2022-06-17T18:39:55ZteorMake node_get_pref_ipv6_orport() check addresses in the right ordernode_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, an...node_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, and relays usually get the correct address from node_get_pref_ipv6_orport() and node_get_prim_orport(), whether they are using microdescriptors or not.
But there are a few cases when this breaks:
* bridge clients should only check routerinfo for configured bridges
* all clients and relays that use microdescs should never check full descriptors (and vice versa, except for the bridge case)
* all clients and relays that use full descriptors should ignore the IPv6 address in the descriptor
* all clients and relays that use microdescriptors should ignore the IPv6 address in the microdescriptor, when using a consensus method that puts IPv6 addresses in the microdesc consensus, otherwise they should use the microdescriptorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33225Prop 311: 4.4.1. Extend IPv6 From All Supported Second-Last Hops2022-06-17T18:01:44ZteorProp 311: 4.4.1. Extend IPv6 From All Supported Second-Last HopsThis is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing legacy/trac#33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachabilit...This is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing legacy/trac#33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
4.4.1. Extend IPv6 From All Supported Second-Last Hops
The testing relay (or bridge) puts both IPv4 and IPv6 ORPorts in its final
extend cell, and the receiving ORPort is selected at random by the
extending relay (see sections 3.2.1 and 4.2). Therefore, approximately half
of IPv6 ORPort reachability circuits will actually end up confirming IPv4
ORPort reachability.
We propose this optional change, to improve the rate of IPv6 ORPort
reachability checks:
If the second-last hop of an IPv4 ORPort reachability circuit supports IPv6
extends, testing relays may put the IPv4 and IPv6 ORPorts in the extend
cell for the final extend.
As the number of relays that support IPv6 extends increases, this change
will increase the number of IPv6 reachability confirmations. In the ideal
case, where the entire network supports IPv4 and IPv6 extends, IPv4 and IPv6
ORPort reachability checks would require a similar number of circuits.
See proposal 311, section 4.4.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n439https://gitlab.torproject.org/tpo/core/tor/-/issues/33043Prop 306: Keep bridge IPv6 behaviour in sync with client behaviour2022-06-17T18:01:01ZteorProp 306: Keep bridge IPv6 behaviour in sync with client behaviourWe should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the ne...We should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the necessary changes, see section 3.3.1 and 3.3.2 of the draft proposal 311:
https://github.com/torproject/torspec/pull/103/files#diff-090a91ed4c8eac745c5ecc316b78dab4R153https://gitlab.torproject.org/tpo/core/tor/-/issues/21311Exits should resolve IPv6 addresses, regardless of IPv6Exit2022-06-17T17:40:46ZteorExits 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 IPv6Exithttps://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/11625Tor DNSPORT returns NXDOMAIN for AAAA records?2022-06-17T16:14:40ZNick MathewsonTor DNSPORT returns NXDOMAIN for AAAA records?On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com...On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com @localhost -p 5304
; <<>> DiG 9.9.5-3-Debian <<>> aaaa gmail.com @localhost -p 5304
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN AAAA
;; Query time: 249 msec
;; SERVER: ::1#5304(::1)
;; WHEN: Sun Apr 27 11:37:35 BST 2014
;; MSG SIZE rcvd: 27
mike@glue:~$ dig +short a gmail.com @localhost -p 5304
173.194.70.18
mike@glue:~$
```https://gitlab.torproject.org/tpo/core/tor/-/issues/21397Tor TransparentProxy documentation: add IPv6 support / port to nftables2022-06-17T16:05:15ZadrelanosTor TransparentProxy documentation: add IPv6 support / port to nftableshttps://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
* add IPv6 support
* port to nftableshttps://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
* add IPv6 support
* port to nftableshttps://gitlab.torproject.org/tpo/core/tor/-/issues/24181v3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service...2022-06-17T14:20:39Zteorv3 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 requestshttps://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/26664When an exit tells a client about an IPv6-only hostname, the client should ch...2022-06-17T14:15:14ZteorWhen an exit tells a client about an IPv6-only hostname, the client should choose another IPv6 exitWhen legacy/trac#21311 and legacy/trac#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 ...When legacy/trac#21311 and legacy/trac#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.https://gitlab.torproject.org/tpo/core/tor/-/issues/31542Cannot connect to IPv6 addresses using Tor SOCKS2022-06-17T12:56:12ZTracCannot connect to IPv6 addresses using Tor SOCKSHere is my Tor configuration:
```
SocksPort 127.0.0.1:9050 IPv6Traffic
SocksPort [::1]:9050 IPv6Traffic
DataDirectory /run/tor_client
ControlPort unix:/run/tor_client/control
ClientUseIPv6 1
```
I'm using 0.4.1.5 on Debian 9.
IPv4 dir...Here is my Tor configuration:
```
SocksPort 127.0.0.1:9050 IPv6Traffic
SocksPort [::1]:9050 IPv6Traffic
DataDirectory /run/tor_client
ControlPort unix:/run/tor_client/control
ClientUseIPv6 1
```
I'm using 0.4.1.5 on Debian 9.
IPv4 direct addresses are fine:
```
$ curl -s -x socks5h://127.0.0.1:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
* Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (127.0.0.1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:54:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact
$ curl -s -x socks5h://[::1]:9050 -v 157.230.170.226
* Rebuilt URL to: 157.230.170.226/
* Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 157.230.170.226:80
* SOCKS5 request granted.
* Connected to (nil) (::1) port 9050 (#0)
> GET / HTTP/1.1
> Host: 157.230.170.226
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Tue, 27 Aug 2019 20:55:03 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://157.230.170.226/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host 157.230.170.226 left intact
```
IPv6 direct addresses do not work:
```
$ curl -s -x socks5h://[::1]:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
* Trying ::1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0000:0000:0000:0000:0000:0000:0000:0000:0. (1)
* Closing connection 0
$ curl -s -x socks5h://127.0.0.1:9050 -v [2604:a880:cad:d0::684e:f001]
* Rebuilt URL to: [2604:a880:cad:d0::684e:f001]/
* Trying 127.0.0.1...
* TCP_NODELAY set
* SOCKS5 communication to 2604:a880:cad:d0::684e:f001:80
* Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
* Closing connection 0
```
What should I test from here?
Thanks!
**Trac**:
**Username**: sega01https://gitlab.torproject.org/tpo/core/tor/-/issues/26971Add rendezvous point unrecognised link specifiers to client introduce cells2022-06-16T18:01:57ZteorAdd rendezvous point unrecognised link specifiers to client introduce cellsLike legacy/trac#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 legacy/trac#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#n1346