Tor browser cannot connect to SOCKS server if it is not specified by IP address

added component::applications/tor browser owner::tbb-team priority::medium reporter::wagon resolution::wontfix severity::normal status::closed type::defect labels

I guess it's related to a feature which has prevented numerous proxy bypasses for DNS requests. We do

+    PRNetAddr tempAddr;
+    if (mDisableDNS) {
+        // Allow IP lookups through, but nothing else.
+        if (PR_StringToNetAddr(aHostname.BeginReading(), &tempAddr) != PR_SUCCESS) {
+            return NS_ERROR_UNKNOWN_PROXY_HOST; // XXX: NS_ERROR_NOT_IMPLEMENTED?
+        }
+    }

network.proxy.socks_remote_dns is the preference which might help you. Assuming I am right then this a WONTFIX. Please reopen otherwise.

Trac:
Status: assigned to closed
Resolution: N/A to wontfix

I see the same problem with torsocks, but torsocks documented it as not yet implemented (man torsocks.conf):

TorAddress ip_addr The IP address of the Tor SOCKS server (e.g "server = 10.1.4.253"). Only one server may be specified. Currently, torsocks does NOT support hostname. (default: 127.0.0.1)

Trac:
Username: wagon

network.proxy.socks_remote_dns is the preference which might help you. You are right. If it is false, it works. However, it is strange that value of this option in user.js is ignored. I have to change it from browser in about:config manually. Why? I found that in /path/to/profile.meek-http-helper it is written

// Make sure DNS is also blackholed. network.proxy.socks_remote_dns is
// overridden by meek-http-helper at startup.

but I don't use transports.

From anonymity point of view using tor as DNS service is not good, as different exit nodes will be used for DNS resolving and for data transfer, which makes tor usage pattern unique. For this task, some intermediate local transparent proxy, which maps myproxy to another IP, is probably better.

Trac:
Username: wagon

Replying to gk:

I guess it's related to a feature which has prevented numerous proxy bypasses for DNS requests. We do {{{
PRNetAddr tempAddr;

if (mDisableDNS) {
   // Allow IP lookups through, but nothing else.
   if (PR_StringToNetAddr(aHostname.BeginReading(), &tempAddr) != PR_SUCCESS) {
       return NS_ERROR_UNKNOWN_PROXY_HOST; // XXX: NS_ERROR_NOT_IMPLEMENTED?
   }
} }}} network.proxy.socks_remote_dns is the preference which might help you. Assuming I am right then this a WONTFIX. Please reopen otherwise. No, that's not for the address of SOCKS proxy for Firefox. See #17991 (moved), #17953 (moved), #17949 (moved), #17901 (moved) for why you can't use hard-coded 127.0.0.1.

Trac:
Username: targetSdkVersion
Resolution: wontfix to N/A
Status: closed to reopened

For this task, some intermediate local transparent proxy, which maps myproxy to another IP, is probably better. There is a very simple solution which requires neither myproxy nor any additional proxy for this steup. It is enough to specify 127.0.0.1 as SOCKS proxy in tor-browser and then redirect 127.0.0.1:port to Tor's IP:port using only [rules]. It may be [an accurate solution from viewpoint of standards] but it is neat, simple, and works fine.

See #17991 (moved), #17953 (moved), #17949 (moved), #17901 (moved) for why you can't use hard-coded 127.0.0.1. I think it is a different problem. Tor-browser works fine with any IP of SocksPort, it is not needed to be hard-coded. This ticket is about using some hostname instead of IP.

Trac:
Username: wagon

Replying to wagon:

See #17991 (moved), #17953 (moved), #17949 (moved), #17901 (moved) for why you can't use hard-coded 127.0.0.1. I think it is a different problem. Tor-browser works fine with any IP of SocksPort, it is not needed to be hard-coded. This ticket is about using some hostname instead of IP.

I agree, closing. FWIW: not sure why user.js is ignored. I have not looked that closely at the code.

Trac:
Status: reopened to closed
Resolution: N/A to wontfix

closed

moved to tpo/applications/tor-browser#28642 (closed)

Tor browser cannot connect to SOCKS server if it is not specified by IP address

Child items 0

Activity