Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:47:34Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32314Can't connect to literal IPv6 address containing double colon2020-06-13T15:47:34ZTracCan'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**: liberatTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32315Can't perform reverse DNS lookup for a (binary) IPv6 address2020-06-13T15:47:35ZTracCan't perform reverse DNS lookup for a (binary) IPv6 addressTor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument ...Tor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument which can either be a binary IPv4 or IPv6 address, or an ASCII string.
Somewhat contrary to ticket #32314, this command works for IPv6 addresses only if the address is specified as an ASCII string (address type 3) with no brackets. If the address is specified in binary (address type 4), or as a string enclosed in brackets, Tor will reject it.
**Trac**:
**Username**: liberatTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32363tor_inet_aton parsing of IPv4 literals is too lax2020-06-13T15:47:46ZTractor_inet_aton parsing of IPv4 literals is too laxThe function tor_inet_aton accepts strings that include leading zeroes.
For example, "010.010.010.010" is parsed as "10.10.10.10".
This could potentially be a problem because "010.010.010.010" is obsolete notation for an _octal_ IP add...The function tor_inet_aton accepts strings that include leading zeroes.
For example, "010.010.010.010" is parsed as "10.10.10.10".
This could potentially be a problem because "010.010.010.010" is obsolete notation for an _octal_ IP address.
At least in glibc, inet_aton or getaddrinfo treats "010.010.010.010" as "8.8.8.8", whereas inet_ntop rejects it as invalid.
**Trac**:
**Username**: liberatTor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org