[tor-bugs] #29989 [Core Tor/Tor]: MapAddress directive added to torrc doesn't work for some websites, fails to assign specified exit node (was: Add a flag to set chosen_exit_optional to false for MapAddress torrc option (and controller?))
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Apr 10 07:36:44 UTC 2019
#29989: MapAddress directive added to torrc doesn't work for some websites, fails
to assign specified exit node
----------------------------------+-----------------------------------
Reporter: babyfarkmcgeezaxxon | Owner: (none)
Type: defect | Status: needs_information
Priority: Medium | Milestone: Tor: unspecified
Component: Core Tor/Tor | Version: Tor: 0.3.5.8
Severity: Normal | Resolution:
Keywords: tor-client, tor-exit | Actual Points: 0.3
Parent ID: | Points: 1
Reviewer: | Sponsor:
----------------------------------+-----------------------------------
Changes (by teor):
* status: new => needs_information
* keywords: security-low?, tor-client, tor-exit => tor-client, tor-exit
* actualpoints: => 0.3
* type: enhancement => defect
Comment:
I also tried to reproduce this error.
(I thought I had understood the code correctly, but I made a mistake.)
Here's what I found:
1. Mappings to duckduckgo and ayefiles use the specified exit
Using the commands:
{{{
tor MapAddress "duckduckgo.com
duckduckgo.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl --proxy socks4a://127.0.0.1:9050 https://duckduckgo.com
}}}
(socks5h works the same.)
I see logs like:
{{{
Apr 10 17:15:36.000 [info] addressmap_rewrite: Addressmap: rewriting
"duckduckgo.com" to
"duckduckgo.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit"
...
Apr 10 17:15:37.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to
duckduckgo.com
}}}
I get similar results when I use ayefiles.com instead of duckduckgo.com.
2. Invalid sites fail, rather than choosing a random exit
{{{
tor MapAddress "foo.invalid
foo.invalid.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl --proxy socks4a://127.0.0.1:9050 foo.invalid
}}}
{{{
Apr 10 17:17:48.000 [info] addressmap_rewrite: Addressmap: rewriting
"foo.invalid" to
"foo.invalid.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit"
...
Apr 10 17:18:05.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to foo.invalid
...
Apr 10 17:18:15.000 [info] connection_ap_expire_beginning: We tried for 10
seconds to connect to 'foo.invalid' using exit
$719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at 185.220.100.252.
Retrying on a new circuit.
...
Apr 10 17:18:16.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to foo.invalid
...
Apr 10 17:18:16.000 [info] connection_ap_process_end_not_open: Address
'foo.invalid' refused due to 'resolve failed'. Considering retrying.
Apr 10 17:18:16.000 [info] client_dns_incr_failures: Address foo.invalid
now has 1 resolve failures.
...
...
Apr 10 17:18:20.000 [info] client_dns_incr_failures: Address foo.invalid
now has 3 resolve failures.
Apr 10 17:18:20.000 [notice] Have tried resolving or connecting to address
'foo.invalid' at 3 different places. Giving up.
}}}
3. IP address requests aren't mapped
{{{
tor MapAddress "duckduckgo.com
duckduckgo.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl --proxy socks4://127.0.0.1:9050 https://duckduckgo.com
}}}
(socks4 does a local DNS resolve, and sends the IP. socks5 has the same
issue.)
{{{
Apr 10 17:21:35.000 [info] link_apconn_to_circ: Looks like completed
circuit to $AC93D396F8E86DC3B6DD80C11CA0871C31670C30~NeelTorExitB at
162.244.80.228 does allow optimistic data for connection to 54.206.51.242
}}}
But if I've recently used the mapped exit, that circuit might get used
again. (Restart Tor to reliably fail to use the exit.)
4. Redirects can also skip the mapping
{{{
tor MapAddress "google.com
google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl -L --proxy socks4a://127.0.0.1:9050 google.com
}}}
{{{
Apr 10 17:28:06.000 [info] addressmap_rewrite: Addressmap: rewriting
"google.com" to "google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit"
...
Apr 10 17:28:07.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to google.com
...
Apr 10 17:28:08.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to
www.google.com
}}}
In this case, tor just happens to use the existing circuit. But that's not
guaranteed.
After restarting Tor:
{{{
tor MapAddress "google.com
google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl --proxy socks4a://127.0.0.1:9050 https://www.google.com
}}}
{{{
Apr 10 17:29:57.000 [info] link_apconn_to_circ: Looks like completed
circuit to $D0D5DF6DF35956DB121A10788668C97E63F04C49~trusty at
178.175.143.165 does allow optimistic data for connection to
www.google.com
}}}
So I'll update the documentation in #30109, but I'm not sure how else we
can help you.
You might need to use MapAddress on the redirect addresses, or maybe the
IP addresses?
The wildcard format might help:
{{{
tor MapAddress "*.google.com
*.google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit" Log "info
stderr" SafeLogging 0
curl -L --proxy socks4a://127.0.0.1:9050 google.com
}}}
{{{
Apr 10 17:33:11.000 [info] addressmap_rewrite: Addressmap: rewriting
"google.com" to "google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit"
...
Apr 10 17:33:12.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to google.com
...
Apr 10 17:33:13.000 [info] addressmap_rewrite: Addressmap: rewriting
"www.google.com" to
"www.google.com.719FD0FA327F3CCBCDA0D4EA74C15EA110338942.exit"
...
Apr 10 17:33:13.000 [info] link_apconn_to_circ: Looks like completed
circuit to $719FD0FA327F3CCBCDA0D4EA74C15EA110338942~F3Netze at
185.220.100.252 does allow optimistic data for connection to
www.google.com
}}}
Otherwise, we really do need the exact steps you're using, and the logs
you see with `Log "info stderr" SafeLogging 0` (you can replace stderr
with a file path).
If you can reproduce this issue using curl, that would help us see what
you're seeing.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29989#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list