Tor 0.3.2 rejects connections to raw ipv6 addresses

changed milestone to %Tor: 0.3.3.x-final in legacy/trac

Trac:
Description: 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]/ 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.

to

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.

Mmm... nice link for testing "Secure Connection Failed"...

Replying to cypherpunks:

Mmm... nice link for testing "Secure Connection Failed"...

That's what happens for me too. That's the point.

Replying to pastly:

Replying to cypherpunks:

Mmm... nice link for testing "Secure Connection Failed"...

That's what happens for me too. That's the point. That happens not every time and is a different bug, fwiw. But warnings in the log look like a Tor bug.

Here is what a Tor 0.3.1.9 gives me just dropped into the same Tor Browser 7.5 with the error in this bug:

[01-26 19:14:18] TorLauncher DBUG: Event response: 650 STATUS_CLIENT WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=2a00:1450:401b:800::200e:443
[01-26 19:14:18] TorLauncher NOTE: WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=2a00:1450:401b:800::200e:443

So, this does indeed to be a Tor issue then, no?

The first bad commit is 7f05f896 which was supposed to fix legacy/trac#22461 (moved).

Trac:
Version: N/A to Tor: 0.3.2.1-alpha
Summary: Tor Browser 7.5 rejects connections to raw ipv6 addresses to Tor 0.3.2 rejects connections to raw ipv6 addresses
Component: Applications/Tor Browser to Core Tor/Tor

Giving this a (hopefully reasonable) milestone because I've heard that if Core Tor/Tor tickets don't have a milestone, they tend to get lost.

Trac:
Milestone: N/A to Tor: 0.3.3.x-final

adding keywords; cc'ing rl1987 as patch author, teor as ipv6 guru, and arma as reviewer.

Trac:
Keywords: N/A deleted, regression ipv6 added
Cc: N/A to teor, rl1987, arma
Priority: Medium to High

Trac:
Keywords: regression ipv6 deleted, regression ipv6 032-backport added

Using string_is_valid_hostname() excludes IPv6 addresses. (It doesn't exclude IPv4 addresses, because they are numbers separated by dots. Let's deal with that in legacy/trac#25055 (moved).)

/** Return true iff <b>string</b> matches a pattern of DNS names
 * that we allow Tor clients to connect to.
 *
 * Note: This allows certain technically invalid characters ('_') to cope
 * with misconfigured zones that have been encountered in the wild.
 */
int
string_is_valid_hostname(const char *string)

We should check both calls introduced by this patch. I think the second call should be modified to include IPv4 and IPv6 addresses. And we should add a unit test for this use case.

I think we should make this function return yes for every string that is a legit destination address -- that is, something that is ok to send in a relay begin cell. (Does that make legacy/trac#25055 (moved) a duplicate of this ticket?)

Speaking of unit tests, it might also be smart to test using socks4a with an ipv6 address as the provided destination name -- I would expect it to work, but based on this ticket I bet it currently doesn't.

I suspect socks4-with-ipv6 has been broken the whole time too.

Quick question on this. Are we sure this is not Tor Browser sending a SOCKS5 request with the type "fqdn" used with an IPv6 address?

That string_is_valid_hostname() check is done when we get an atyp = 0x03 in the SOCKS5 request which means tor should expect a FQDN thus returning the error here is fine. The IPv6 address is handled before.

Why is TB sending a fqdn request at all with this address: https://[2a00:1450:401b:800::200e]/ ?

Trac:
Status: new to needs_information

Replying to dgoulet:

Quick question on this. Are we sure this is not Tor Browser sending a SOCKS5 request with the type "fqdn" used with an IPv6 address?

That string_is_valid_hostname() check is done when we get an atyp = 0x03 in the SOCKS5 request which means tor should expect a FQDN thus returning the error here is fine. The IPv6 address is handled before.

Why is TB sending a fqdn request at all with this address: https://[2a00:1450:401b:800::200e]/ ?

Technically, you are correct: Tor Browser should not send IP addresses as strings at all. But if it does, we should handle them sensibly.

Here are the possible types:

ATYP   address type of following address
             o  IP V4 address: X'01'
             o  DOMAINNAME: X'03'
             o  IP V6 address: X'04'

See section 4 in https://tools.ietf.org/html/rfc1928

Here are the specs for each type:

In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
   the type of address contained within the field:

          o  X'01'

   the address is a version-4 IP address, with a length of 4 octets

          o  X'03'

   the address field contains a fully-qualified domain name.  The first
   octet of the address field contains the number of octets of name that
   follow, there is no terminating NUL octet.

          o  X'04'

   the address is a version-6 IP address, with a length of 16 octets.

So IPv4 and IPv6 should be binary encoded. And all strings should be FQDNs.

Tor Browser is obviously sending IPv4 and IPv6 addresses as text, in violation of the spec. Tor has always accepted IPv4 addresses as text, in violation of the spec. Therefore, we should accept IPv6 addresses as text, just like we did in 0.3.1. Because we can't break a feature like this.

Trac:
Status: needs_information to new

Replying to teor:

Replying to dgoulet:

Quick question on this. Are we sure this is not Tor Browser sending a SOCKS5 request with the type "fqdn" used with an IPv6 address?

That string_is_valid_hostname() check is done when we get an atyp = 0x03 in the SOCKS5 request which means tor should expect a FQDN thus returning the error here is fine. The IPv6 address is handled before.

Why is TB sending a fqdn request at all with this address: https://[2a00:1450:401b:800::200e]/ ? Tor Browser is obviously sending IPv4 and IPv6 addresses as text, in violation of the spec. Tor has always accepted IPv4 addresses as text, in violation of the spec. Therefore, we should accept IPv6 addresses as text, just like we did in 0.3.1. Because we can't break a feature like this.

Well Tor Browser ships its own "tor" so it can fix this and just use a "tor" that have this working?

I do see the importance of not breaking a feature even though it means violating the spec but with TB, it controls the whole chain. If TB can't fix this, then I agree that tor should just revert to accepting IPv4/IPv6 string values.

Replying to dgoulet:

Replying to teor:

Replying to dgoulet:

Quick question on this. Are we sure this is not Tor Browser sending a SOCKS5 request with the type "fqdn" used with an IPv6 address?

That string_is_valid_hostname() check is done when we get an atyp = 0x03 in the SOCKS5 request which means tor should expect a FQDN thus returning the error here is fine. The IPv6 address is handled before.

Why is TB sending a fqdn request at all with this address: https://[2a00:1450:401b:800::200e]/ ? Tor Browser is obviously sending IPv4 and IPv6 addresses as text, in violation of the spec. Tor has always accepted IPv4 addresses as text, in violation of the spec. Therefore, we should accept IPv6 addresses as text, just like we did in 0.3.1. Because we can't break a feature like this.

Well Tor Browser ships its own "tor" so it can fix this and just use a "tor" that have this working?

I do see the importance of not breaking a feature even though it means violating the spec but with TB, it controls the whole chain. If TB can't fix this, then I agree that tor should just revert to accepting IPv4/IPv6 string values.

Many SOCKS5 clients use Tor 0.3.2. Tor needs to allow them all to send IP addresses as hostnames, as we did in 0.3.1.

Tor Browser may do a temporary fix, that's up to them.

I think we should ignore the spec and do the right thing. The right thing is that if you get an address string that is usable as a destination address, you should use it.

Replying to arma:

I think we should ignore the spec and do the right thing. The right thing is that if you get an address string that is usable as a destination address, you should use it.

Usability, I agree and less hassle of broken apps opening tickets. Flip side, we let flourish an ecosystem of broken applications that uses SOCKS the wrong way and in this case, Tor Browser.

But I won't argue more, I think TB knows what to do to do it right and "tor" can just be lenient with what format the address comes in (binary or text).

Preliminary patch for this (and legacy/trac#25055 (moved)): https://github.com/rl1987/tor/commits/bugs_25036_25055

I'm not exactly sure if it's okay to feed bracketed IPv6 string into tor_inet_pton, but it seems to work.

Trac:
Status: new to needs_review

Tor 0.3.2 rejects connections to raw ipv6 addresses

Child items ...

Activity