{"id":243,"date":"2015-08-19T16:17:39","date_gmt":"2015-08-19T21:17:39","guid":{"rendered":"http:\/\/www.p14nd4.com\/blog\/?p=243"},"modified":"2015-08-19T16:17:39","modified_gmt":"2015-08-19T21:17:39","slug":"using-elinks-with-tor-torify-torsocks","status":"publish","type":"post","link":"http:\/\/www.p14nd4.com\/blog\/2015\/08\/19\/using-elinks-with-tor-torify-torsocks\/","title":{"rendered":"Using ELinks with Tor \/ torify \/ torsocks"},"content":{"rendered":"

I recently tried to use the ELinks<\/a> console-based web browser with Tor<\/a>. I found what seemed<\/em> to be the easiest way to this: torify elinks<\/a>, but that turned into a journey down the rabbit-hole. (A wiser man than I likely would’ve just used the alternate method suggested there—privoxy—but for the next one of me who comes along, here’s what I found.)
\n<\/p>\n

The first issue I ran into was that elinks didn’t seem to be going through the proxy defined by LD_PRELOAD \/ torsocks config (verified by the inability to resolve .onion addresses and a what-is-my-ip page check). That solution, stupidly enough, was to exit the other instance of elinks that I had running. I suppose that because of the use of shared libraries, solutions like this are a first-come-first-serve deal.<\/p>\n

Getting past that, I ran into the real<\/em> issue: regular web traffic was going through tor, but attempting to resolve *.onion addresses resulted in failure and a few of these warnings: WARNING torsocks[12360]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c<\/code><\/p>\n

My normal approach of searching for help didn’t turn up anything useful for that warning or queries like ‘torsocks elinks’ or ‘torify elinks’ or ‘elinks dns’, so I put on my hard-hat and went to work. The first order of business was to turn up the volume. From the torsocks(8) manpage, I learned I could get some more debug messages like this: TORSOCKS_LOG_LEVEL=5 TORSOCKS_LOG_FILE_PATH=\/tmp\/torsocks.log torsocks elinks<\/code><\/p>\n

After reproducing the error, I dug into the log file and found this interesting excerpt (.onion address changed):<\/p>\n

\n
[Aug 19 14:23:51] DEBUG torsocks[11152]: [getaddrinfo] Requesting SPGmA7pu1CsgVBNW.onion hostname (in tsocks_getaddrinfo() at getaddrinfo.c:44)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: Resolving SPGmA7pu1CsgVBNW.onion on the Tor network (in tsocks_tor_resolve() at torsocks.c:527)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [onion] Finding onion entry for name SPGmA7pu1CsgVBNW.onion (in onion_entry_find_by_name() at onion.c:229)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [onion] Creating onion entry for name SPGmA7pu1CsgVBNW.onion (in onion_entry_create() at onion.c:174)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [onion] Entry added to the onion pool at index 0 (in insert_onion_entry() at onion.c:79)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [onion] Entry added with IP address 127.42.42.0 used as cookie (in onion_entry_create() at onion.c:207)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [getaddrinfo] Node SPGmA7pu1CsgVBNW.onion resolved to 127.42.42.0 (in tsocks_getaddrinfo() at getaddrinfo.c:107)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: Close catched for fd 10 (in tsocks_close() at close.c:33)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [onion] Destroying onion pool containing 1 entry (in onion_pool_destroy() at onion.c:148)\r\n[Aug 19 14:23:51] DEBUG torsocks[11152]: [fclose] Close catched for fd 4 (in tsocks_fclose() at fclose.c:45)\r\n[Aug 19 14:23:51] DEBUG torsocks[11150]: Close catched for fd 9 (in tsocks_close() at close.c:33)\r\n[Aug 19 14:23:51] DEBUG torsocks[11150]: [socket] Creating socket with domain 2, type 1 and protocol 6 (in tsocks_socket() at socket.c:33)\r\n[Aug 19 14:23:51] DEBUG torsocks[11150]: Connect catched on fd 9 (in tsocks_connect() at connect.c:112)\r\n[Aug 19 14:23:51] DEBUG torsocks[11150]: [connect] Socket family AF_INET and type 1 (in validate_socket() at connect.c:77)\r\n[Aug 19 14:23:51] DEBUG torsocks[11150]: [onion] Finding onion entry for IP 127.42.42.0 (in onion_entry_find_by_addr() at onion.c:268)\r\n[Aug 19 14:23:51] WARNING torsocks[11150]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c:186)<\/pre>\n<\/blockquote>\n
I’ll save you some of the details, since they’re long and boring, but after looking through source code for both torsocks and elinks, I eventually discovered that elinks [apparently] resolves hostnames asynchronously by default. Torsocks doesn’t maintain its onion ‘pool’ (a struct with protections for atomic access, containing an array mapping fake IP addresses (‘cookies’) to their hidden service *.onion hostname) between instances, so when elinks resolves the IP address for blah.onion in another thread, and then passes back the address ‘127.42.42.0’ to the thread trying to create the HTTP socket (the actual TCP request), it fails. The torsocks instance (private memory space) for the http thread has no record of the ‘127.42.42.0 = blah.onion’ mapping, which is needed for the connection to go through, and thus it fails.<\/p>\n
Like a typical FOSS<\/acronym> user, I took the easy way out instead of actually working on a way to correct the issue<\/q> in torsocks (it’s better to do this than share system-wide, so may be a feature,<\/q> but I think it should still be shared\/cached per-user). My workaround was to disable asynchronous DNS lookups in elinks in my ~\/.elinks\/elinks.conf as follows: set connection.async_dns = 0<\/code><\/p>\n","protected":false},"excerpt":{"rendered":"
I recently tried to use the ELinks console-based web browser with Tor. I found what seemed to be the easiest way to this: torify elinks, but that turned into a journey down the rabbit-hole. (A wiser man than I likely would’ve just used the alternate method suggested there—privoxy—but for the next one of me who […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-243","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/comments?post=243"}],"version-history":[{"count":8,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/243\/revisions"}],"predecessor-version":[{"id":254,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/243\/revisions\/254"}],"wp:attachment":[{"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/media?parent=243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/categories?post=243"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/tags?post=243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}