#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs