Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6545 closed defect (invalid)

Isolation level may be funky and share circuits?

Reported by: sdjfjsdfiuhszduh Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I am using tor 2.3.19-rc for windows. The below i quote the Docs.

I have 7 SOCKSPort (SOCKSPort 9050 bc TBB wont allow me to use any other ports, + SOCKSPort 1230-1235)
Using vidalia i look at my circuits and i only have 5. With an app i check my IP Address using "https://check.torproject.org/?lang=en-US&small=1&uptodate=1" and throw an error if there are duplicate ipaddresses. I use a simple webrequest using privoxy as my proxy

The result was 3 of the 7 got an ip while the others failed. I tried running repeatedly. I'm not sure i only have 5 circuits but i am only using 3 of them for the 7instance (all using different ports). Later on when i had more circuits i tried. Again only 3 were unique.

Perhaps this is a bug? I pretty much used the default TBB but replaced files from the new tor, removed one line bc it was incompatible with SOCKSPort (port 9050) then add additional 6 SOCKSPort for different ports. I turn on tor the same way i normally do with TBB. I click a shortcut. This is installed on a portable drive.

IsolateClientAddr

Don’t share circuits with streams from a different client address. (On by default and strongly recommended; you can disable it with NoIsolateClientAddr.)

Child Tickets

Change History (18)

comment:1 in reply to:  description Changed 7 years ago by sdjfjsdfiuhszduh

I forgot to mention later on when i had 8 circuits, i tried again and still only 3 were unique.

comment:2 Changed 7 years ago by nickm

Component: - Select a componentTor Client
Milestone: Tor: 0.2.3.x-final

Equal exit nodes are not a sure sign of same circuits. The goal of circuit isolation is not to ensure that streams don't go over the same exit, but rather to keep any exit from reliably inferring that those streams are coming from the same client by sending them on the same circuit. (And also, to keep any server from deducing that those two streams are likelier to come from the same client by making them more likely to come from the same exit than they would otherwise.)

That said, it seems pretty weird to get so few distinct exits chosen. Do you have any options set in your configuration that might affect how exits are getting selected?

comment:3 in reply to:  2 Changed 7 years ago by sdjfjsdfiuhszduh

Replying to nickm:

Equal exit nodes are not a sure sign of same circuits. The goal of circuit isolation is not to ensure that streams don't go over the same exit, but rather to keep any exit from reliably inferring that those streams are coming from the same client by sending them on the same circuit. (And also, to keep any server from deducing that those two streams are likelier to come from the same client by making them more likely to come from the same exit than they would otherwise.)

That said, it seems pretty weird to get so few distinct exits chosen. Do you have any options set in your configuration that might affect how exits are getting selected?

I don't think i do. Its the TBB with the unstable version of tor (I upgraded to 0.2.3.20-rc which seems to have the same effect) but I changed one line to use SocksPort and added many more SocksPort. Here is a copy

# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it

AvoidDiskWrites 1
ControlPort 9051
DataDirectory .........../Tor Browser/Data/Tor
DirReqStatistics 0
GeoIPFile .\Data\Tor\geoip
Log notice stdout
SocksPort 9050
SocksPort 6 more of these

comment:4 in reply to:  2 Changed 7 years ago by sdjfjsdfiuhszduh

Replying to nickm:

Equal exit nodes are not a sure sign of same circuits. The goal of circuit isolation is not to ensure that streams don't go over the same exit, but rather to keep any exit from reliably inferring that those streams are coming from the same client by sending them on the same circuit. (And also, to keep any server from deducing that those two streams are likelier to come from the same client by making them more likely to come from the same exit than they would otherwise.)

That said, it seems pretty weird to get so few distinct exits chosen. Do you have any options set in your configuration that might affect how exits are getting selected?

I'll also add that it isn't just using the same exit nodes. It using the same circuits! Lately theres been about 10+ circuits available on startup (within first 20seconds). All activity still goes through the same 3 circuits....

If you want to recreate it just have 7 SocksPort with an http proxy, configure one app to take in a proxyaddr/port/url via command line then run them all. It really seems it uses only 3 connections no matter what (except MAYBE if a connections been alive for so long and tor client decides to use a different 3 ports but i havent confirmed that)

comment:5 Changed 7 years ago by weasel

Can't really reproduce this. Isolation seems to work for me:

weasel@valiant:~/tmp$ cat torrc
SocksPort 19050
SocksPort 19051
SocksPort 19052
SocksPort 19053
SocksPort 19054
SocksPort 19055
SocksPort 19056
SocksPort 19057
weasel@valiant:~/tmp$ for i in `awk '$1=="SocksPort" {print $2}' torrc`; do echo "server_port = $i" > torsocks.conf-$i; done
weasel@valiant:~/tmp$ for p in `awk '$1=="SocksPort" {print $2}' torrc`; do (while : ; do TORSOCKS_CONF_FILE=torsocks.conf-$p; echo $p `torsocks wget -q -O - http://www.whatismyip.com/ | w3m -T 'text/html' -dump | grep 'Your IP Addr'`; sleep 5; done)&; done
19056 Your IP Address Is: 178.216.200.34
19050 Your IP Address Is: 31.172.30.3
19051 Your IP Address Is: 93.182.129.86
19055 Your IP Address Is: 173.254.216.68
19056 Your IP Address Is: 178.216.200.34
19053 Your IP Address Is: 64.250.116.70
19052 Your IP Address Is: 176.31.121.48
19050 Your IP Address Is: 31.172.30.3
19057 Your IP Address Is: 93.182.129.84
19051 Your IP Address Is: 93.182.129.86
19055 Your IP Address Is: 173.254.216.68
19054 Your IP Address Is: 198.144.180.18
19056 Your IP Address Is: 178.216.200.34
19052 Your IP Address Is: 176.31.121.48
19050 Your IP Address Is: 31.172.30.3
19051 Your IP Address Is: 93.182.129.86
19056 Your IP Address Is: 178.216.200.34
19055 Your IP Address Is: 173.254.216.68
19057 Your IP Address Is: 93.182.129.84
19054 Your IP Address Is: 198.144.180.18

..

weasel@valiant:~$ sudo netstat -npt | grep 25905 | grep -v 127.0.0.1
tcp        0      0 172.22.118.10:36872     50.115.125.52:443       ESTABLISHED 25905/tor
tcp        0      0 172.22.118.10:49717     91.121.210.207:8080     ESTABLISHED 25905/tor
tcp        0      0 172.22.118.10:57962     173.254.216.67:443      ESTABLISHED 25905/tor

So it seems to exit via a couple different exits, so it must use a couple different circuits to get there. As expected, they all start with one of my existing three guards, so that's why there are only three connections outgoing.

comment:6 Changed 7 years ago by nickm

Tried myself; can't reproduce.

I hacked up the Tor source with this diff to make it loud about attaching stuff. (I should have used existing logs, but I'm lazy):

diff --git a/src/or/control.c b/src/or/control.c
index 61a9f72..f7c51c8 100644
--- a/src/or/control.c
+++ b/src/or/control.c
@@ -3658,6 +3658,15 @@ control_event_stream_status(entry_connection_t *conn, stream_status_event_t tp,
   const char *purpose = "";
   tor_assert(conn->socks_request);
 
+  circ = circuit_get_by_edge_conn(ENTRY_TO_EDGE_CONN(conn));
+  if (circ && CIRCUIT_IS_ORIGIN(circ))
+    origin_circ = TO_ORIGIN_CIRCUIT(circ);
+  write_stream_target_to_buf(conn, buf, sizeof(buf));
+  log_notice(LD_CONTROL, "TEST Stream=%llu Circ=%llu Target=%s",
+             (uint64_t) ENTRY_TO_CONN(conn)->global_identifier,
+             origin_circ ? (uint64_t) origin_circ->global_identifier : 0ull,
+             buf);
+
   if (!EVENT_IS_INTERESTING(EVENT_STREAM_STATUS))
     return 0;
 

Then I ran Tor with this torrc:

SocksPort 9050
SocksPort 9051
SocksPort 9052
SocksPort 9053
SocksPort 9054
SocksPort 9055
SocksPort 9056
SocksPort 9057

and I used this script to generate connections:

#!/bin/bash

for X in 1 2 3 4 5; do
 for socksport in 50 51 52 53 54 55 56 57; do
   curl --socks4a 127.0.0.1:90$socksport www.x$socksport.com > /dev/null
 done
done

and this script to postprocess the log and look for any websites sharing a circuit that shouldn't:

#!/usr/bin/python

import re
import sys

streamTarget = {}
circTargets = {}

for line in sys.stdin:
    m = re.search(r'TEST Stream=(\d+) Circ=(\d+) Target=(.*)', line)
    if not m:
        continue
    s, c, t = m.groups()
    if s not in streamTarget:
        streamTarget[s] = t
    if c != '0':
        circTargets.setdefault(c, set()).add(streamTarget[s])

for c in circTargets:
    if len(circTargets[c]) > 1:
        print c, circTargets[c]
    else:
        print c, "OK"

In other words, two streams with different socksports never went to the same circuit.

Hm. Are you using hidden services here or something? What, *exactly* is the configuration of your http proxy and your application here? If we can track down what's different between your tests and the ones weasel and I are running above, we might be able to figure out what's up with this ticket.

comment:7 Changed 7 years ago by nickm

Status: newneeds_information

comment:8 in reply to:  6 ; Changed 7 years ago by rransom

Replying to nickm:

Tried myself; can't reproduce.

I hacked up the Tor source with this diff to make it loud about attaching stuff. (I should have used existing logs, but I'm lazy):

Not lazy enough. Next time, use my isolation-debug-v4 branch. (Merging it would break the non-spec-compliant Python crap, and its output format is not good enough to be written into the spec, so I haven't tried to get it merged into Tor.)

Hm. Are you using hidden services here or something? What, *exactly* is the configuration of your http proxy and your application here? If we can track down what's different between your tests and the ones weasel and I are running above, we might be able to figure out what's up with this ticket.

The hidden service code shouldn't cause this. I would suspect the HTTP proxy first here, but also, the reporter clearly does not understand what ‘IsolateClientAddr’ means. (The ‘SessionGroup’ feature is what separates streams on different SocksPorts.)

comment:9 in reply to:  8 Changed 7 years ago by nickm

Replying to rransom:

The hidden service code shouldn't cause this.

But do we need more hidden service code to ensure that stream isolation works properly with hidden service requests?

I would suspect the HTTP proxy first here, but also, the reporter clearly does not understand what ‘IsolateClientAddr’ means. (The ‘SessionGroup’ feature is what separates streams on different SocksPorts.)

To be clear, though, different SocksPorts are put into different SessionGroups by default. You don't need to specify an explicit SessionGroup to make streams on different SocksPorts isolated from one another .

comment:10 in reply to:  6 Changed 7 years ago by sdjfjsdfiuhszduh

Resolution: invalid
Status: needs_informationclosed

comment:11 Changed 7 years ago by sdjfjsdfiuhszduh

Ahhhhhhhhhhhhhhh FDSGYASDFJIDFIUHDSUHUSUDHUHDFHDU
I'm an idiot, I'm an idiot, I'm an idiot!

.NET (which is ridiculously easy to use and lets me hack up code as fast as python) doesn't support SOCKs directly (Both HttpWebRequest and the higher level WebClient). So used privoxy but somehow I %&*(ing configured all the listening ports correctly and forgot to change the forwarding port.

It works correctly 100% and i set the ticket to invalid :(. $%&*

comment:12 Changed 7 years ago by nickm

Don't worry about it -- this wasn't the first bogus bug, and it won't be the last.

I'm an idiot, I'm an idiot, I'm an idiot!

Naw: a real idiot you would have just walked away after finding out that the bug report was mistaken, and not bothered to tell us so. ;)

If you want to be extra-extra helpful, can you check to make sure it works with two connections to the same hidden service made from different SocksPorts?

comment:13 in reply to:  11 ; Changed 7 years ago by rransom

Replying to sdjfjsdfiuhszduh:

.NET (which is ridiculously easy to use and lets me hack up code as fast as python) doesn't support SOCKs directly (Both HttpWebRequest and the higher level WebClient).

Is the source code for these modules/components/classes/objects/whatevers available? Have you audited them to check for DNS-query leaks and other anonymity risks?

What you do with your own computer and its configuration is really none of our business (except to the extent that we need to know about it in order to understand/verify/resolve a bug report), but you seem to be the same person that wrote an ‘encrypted PM’ application which uses Tor, and DNS leaks (or other anonymity flaws) in that application could put other people at risk, too.

comment:14 in reply to:  12 Changed 7 years ago by sdjfjsdfiuhszduh

Replying to nickm:

Don't worry about it -- this wasn't the first bogus bug, and it won't be the last.

I'm an idiot, I'm an idiot, I'm an idiot!

Naw: a real idiot you would have just walked away after finding out that the bug report was mistaken, and not bothered to tell us so. ;)

If you want to be extra-extra helpful, can you check to make sure it works with two connections to the same hidden service made from different SocksPorts?

ummm what really from hidden services? Ok sure. I wrote some code thinking it was a windows bug and since i have this setup......

Theres no what to look at an ipaddress so i just watched the circuits in vidalia. After running it twice and unsure if it uses a different circuit each time i used a screen cap program which i use to occasionally do software demos.

It still looked unique so i replayed it slowly. I had 6 connection (although not all at once) to the same hidden service and it all went through different connections.

Consider it as working :)

comment:15 in reply to:  13 Changed 7 years ago by sdjfjsdfiuhszduh

Replying to rransom:

Replying to sdjfjsdfiuhszduh:

.NET (which is ridiculously easy to use and lets me hack up code as fast as python) doesn't support SOCKs directly (Both HttpWebRequest and the higher level WebClient).

Is the source code for these modules/components/classes/objects/whatevers available? Have you audited them to check for DNS-query leaks and other anonymity risks?

What you do with your own computer and its configuration is really none of our business (except to the extent that we need to know about it in order to understand/verify/resolve a bug report), but you seem to be the same person that wrote an ‘encrypted PM’ application which uses Tor, and DNS leaks (or other anonymity flaws) in that application could put other people at risk, too.

I did write that and this had nothing to do with that. Except just learning more about tor and playing around. I'm very unsure how to check DNS leaks. For the app i written I actually didn't consider blocking out onion URLs if there are no proxies being used. I actually just use a TCP socket, use dns to connect to the address UNLESS there is a proxy in which case I plug the domain through the proxy. So you're only at risk if you forget to configure the socks proxy and use a secretive url.

comment:16 in reply to:  13 Changed 7 years ago by sdjfjsdfiuhszduh

Replying to rransom:

Is the source code for these modules/components/classes/objects/whatevers available? Have you audited them to check for DNS-query leaks and other anonymity risks?

To make you feel more comfortable. When there is a proxy I don't put the domain to connect to anywhere except in the SOCKS protocol which is really simple.

comment:17 Changed 7 years ago by nickm

Keywords: tor-client added

comment:18 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.