Closed nyxnor closed 2 years ago
so torsocks creates two streams, in this case, 12947
and 12948
to establish (SUCCEED)` for the wanted connection, this means torsocks will have two tables, one for resolving the hostname that will be presented as:
Stream: 14142, Target: 116.202.120.181:42 (check.torproject.org:42)
Circuit: 10738, Purpose: GENERAL
and
Stream: 14143, Target: 116.202.120.181:443 (116.202.120.181:443)
Circuit: 10739, Purpose: GENERAL
two streams, and if the SocksPort flag has stream isolation with IsolateDestPort
, then it will use another circuit, or maybe IsolateDestAddr
is enough because it first try the hostname then second it try directly the ip address.
TODO: cache every REMAP
after SETNCONNECT
or SETNRESOLVE
, only if the SENTCONNECT
is a hostname, not an IP
problem is that a cached variable is not saving because of subshell usage
Adrelanos said:
I didn't know what that IP is. Can be found on search engines (check.torproject.org) but that isn't comfortable to find out about unwanted connections. Could you please add reverse DNS as an additional field?
Fixed now
Steps to reproduce:
From another instance:
Go back and see outout and finish:
My understanding is that with torsocks, it first sends a
SENTRESOLVE
to resolve the hotname with tor, gets the ip and close the connection. Than it opens another connection directly to that ip.As there is no
SUCEEDED
from the resolve stream, it justREMAP
andCLOSED
, the resolve hostname is never saved. Then it procedes to the next lines which does not contain the hostname, only the ip and is saving only the ip of course as the hostname was never cached bytor-ctrl-stream
.