logs archiveIRC Archive / Oftc / #tor / 2010 / July / 11 / 1
MeCooL
(Action) brb
abstracted
So I'm wondering, how does running a relay with ContactInfo to a non anonymous address effect my privacy?
I'm just trying to reason it out. So in principle someone could reason out that I am a tor user. Any other consequences?
atagar
They'll know you're a relay operator and that's about it. Though be careful what you put there (due to potential spamming)
be aware that the list of relays is public, so if you're trying to hide your identity that's not the thing to do ;)
abstracted
atagar, thanks yes I see that in the well commented example config file :)
atagar
Currently arm is just for relay operators but with a few tweaks it might be useful for clients as well. Any tor users in the channel interested in a command line tool for monitoring tor? If so, what sort of information would you like it to provide?
abstracted
Tor relay traffic is on tcp?
atagar
abstracted: yup, tor handles tcp traffic only (no udp)
abstracted
atagar, thanks :). I'm hopefully setting this up with bridge mode for now until I figure out how I want to handle it long term.
atagar
abstracted: thanks for running a bridge then!
         

Goldstein
Do any of the tor devs actually use git over tor or whatever collaboration software you use?
And if so, how does that work for you?
abstracted
since git can use http among other protocols, i'd think that'd work just fine
but no i'm not dev and haven't tried :)
Goldstein
yeah but I'm curious how practical it is
if someone actually did it, it would say a lot
atagar
Goldstein: Not sure what's special about git over tor. Do you have a particular question you're hoping to have answered?
Goldstein
I wanna know how anoying it is to deal with tor's latency when deving with git and tor
velope
the network communication for git is a batch-mode sync between database replicas. latency shouldn't matter much--less of an issue than web browsing.
atagar:i would try out arm -- in its current form, would i see much of anything at a client?
atagar
velope: yup, it would give pid stats, log output, and bandwidth usage
the header panel is specialized for relays (with the fingerprint, flags, orport, etc) so not sure what to replace that information with...
hence my curiosity what tor client users want :)
velope
if you saw yesterday's discussion about exclude*nodes --
you could make up for a vidalia shortcoming by showing the purpose of each circuit -- is that available in the current control protocol?
atagar
The purpose? I can get the fingerprints for the client circuit and display information about those relays (such as what the exiting ip is). Is that what you mean?
velope
[warn] Requested exit node 'Unnamed' is in ExcludeNodes or ExcludeExitNodes. Using anyway (circuit purpose 5).
atagar
Ahhh, ok. Not a clue what what code is for (looking it up...)
Etsil
Is TorK a good program to use?
Avicennasis
Ello! I'm having some trouble finding what I need in the documentation: How does one setup an exit policy?
atagar
Etsil: I recall liking the interface, but be warned that it's unmaintained
Etsil
Ok....
atagar
velope: quick grep shows that code means "Client-side circuit purpose: Normal circuit, with cpath."... what would you like displayed for the purpose?
Etsil
Is it better just to stay with Vidalia ?
velope
Etsil: most people use vidalia.
Etsil
Ok....good...thanks.
velope
Avicennasis: https://www.torproject.org/docs/tor-doc-relay.html.en
         

atagar
Avicennasis: Depends on what you're trying to do. There's examples in the sample torrc. First match wins.
velope
atagar: what i think people would like to know is stuff like
whether or not a circuit is exiting to the open internet, whether it's used for hidden services, and so forth.
Avicennasis
I see the pretty checkboxes in the GUI, but I want to restrict traffic only to certain IPs. I believe it's possible, as I think I had such a setup before, but don't recall what I did as it was years ago.
velope atagar ^^ :) Thanks.
Believe theres a config file somewhere to edit.
velope
that purpose code might or might not be a reliable indicator -- nickm has mumbled about it.
Etsil
I tried to use Tor to connect to OFTC but got banned. What's the problem?
velope
Etsil: it's not you personally that's been banned -- it's the exit node.
Etsil
Is there a way to fix that problem?
Goldstein
no
Etsil
Should I try a different identity using Vidalia?
Goldstein
yes
Etsil
Thanks
velope
Etsil: wait, that's unlikely to work.
you have to be very lucky or very persistent to find an exit that's not banned.
Goldstein
not on oftc
Etsil
Any suggestions?
Ok...thanks
velope
there is a tor hidden service that serves as a proxy -- only to OFTC.
Goldstein
i have no problem with oftc and tor
velope
in your irc client, try configuring 37lnq2veifl4kar7.onion as the server (port 6667, no SSL).
Goldstein: i think OFTC has silently 'grandfathered' some nicks, but new ones are unlikely to work.
Goldstein
doubt it
velope
that's what happened to me.
Goldstein
u connect b4 it knows you're nick
Etsil
Goldstein.....I missed everything you typed after "not on oftc"
Could repeat it.
velope
it very soon thereafter knows your nick and disconnects.
Goldstein
I have no problem with oftc and tor
velope
Etsil: while you were out: velope: in your irc client, try configuring 37lnq2veifl4kar7.onion as the server (port 6667, no SSL).
Goldstein: awesome for you!
Goldstein
Etsil: but using the hidden service would be fine
atagar
Etsil: http://tor.pastebin.com/rpYReqhm
Goldstein
Etsil: you could ask what the real deal is on #oftc
velope
atagar: as usual armadev was exactly on point -- look at what vidalia shows and see if you can do better, or expose (slightly) more of what the control protocol provides, for the more technical users.
atagar
velope: I'll try, though a lot of what vidalia does is gui based, for instance, can't show a map via a CLI :)
velope
the map is eye candy, at least at its current functionality.
atagar
also, I'm suspecting it's targeting a different audience (vidalia tries to be accessable, while CLI users tend to be a tad more advanced)
also, vidalia goes for cross platform capability while I just need to worry about mac/linux/bsd, so anything accessable via system tools (ps, netstat, etc) is fair game
velope
well then, when you click on a node, show its entire descriptor and everything the client knows about it.
atagar
yup, can do (currently doing that for detected connections)
velope
i have often gone digging in the cached descriptors.
atagar
however, I'm not expanding client connections to provide the relays deeper into the circuit so that's one thing I could fix
ah - what sort of information would you like from the descriptors?
velope: currently I'm providing something like... http://www.atagar.com/arm/images/screenshot_page2_full.png
velope
why not just make it all available?
atagar
it does that too
(press 'd' on a connection to display the full descriptor and ns entry)
velope
yup, looks like you've got plenty there already.
atagar
it could be organized a little nicer for clients though (just added to todo)
what sort of information do you think should be in the header to replace the relay information?
velope
could show which misc. ports are open (that the log file shows at startup) -- dnsport, transport, etc.
i hope you don't rely on getting much from dns on the machine where arm is running -- the client might be using tor for all dns resolution and not resolving anything locally.
atagar
velope: I'm doing reverse dns lookups for relays. I should skip doing that for client connections, would be dangerous.
(currently only on request, but still should be skipped)
velope
on request via tor would be nice.
atagar
Seems very bad, that would be leaking client connections to the exit
velope
"the exit"?
atagar
if you're resolving it via tor it's going unencrypted through the exit you're using
velope
could be any exit.
atagar
Not following. If you're using relay A, B, C for a client circuit it's a very bad idea to ask C to resolve the ips for A, B, and C.
velope
actually just for A right? it already knows itself and that it's talking to B.
atagar
yup
velope
i suppose one should think twice about a request for A, but the exit doesn't know that A is the entry.
atagar
concerning "could show which misc. ports are open" could you clarify more?
velope
but definitely any dns should be on request only -- if done automatically, it would make analysis easy.
atagar
yup
velope
if you see the startup log messages, you find out
whether you configured a dnsport, transport, etc. and whether they were successfully opened. might be nice to know this after the log messages might be gone.
Smark
so I figured out how to split screens with "screen" and C-a S or C-a |... Now is it possible to detach all of those screens as a group so when I do "screen -x name" it automatically brings up all my split windows? I'm trying to make a little bit of a display thing via SSH
atagar
velope: not spotting it... http://tor.pastebin.com/TW6vsWJe
Need something set in particular? Different version?
Smark: probably best to ask in #nottor
Smark
oh, im totally sorry, I thought this was a different channel, my bad... was wondering what the tor talk was. appologies.
velope
[notice] Opening Socks listener on 127.0.0.1:9050
[notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040
[notice] Opening DNS listener on 127.0.0.1:53
atagar
Ahhh, those
velope
i suppose that log info could be correlated with what netstat says.
atagar
What more would you hope to get from netstat?
velope
netstat confirms that a port is (still) open; the log open shows that tor opened it and what for.
s/open/output/
atagar
velope: For non-relays I'd like to omit netstat requests entirely if there isn't need, but great idea about including it in the header (thanks!)
velope
i'm sure that's fine, but does arm still use netstat for relays? how would clients differ in that regard?
atagar
For relays tor doesn't provide any information about the circuits so arm uses netstat to get the listing. For clients however I already have the fingerprints and ns entries so doesn't seem necessary.
velope
OK.
atagar
Know if there's a way of checking if all traffic's going through tor? Seems like that might be useful in case the user's unaware that something's leaking.
could list all network activity for clients, noting what's going through tor and what's not... hmmm....
velope
umm, i thought you didn't want to run stuff like netstat ...
the thing that does what you're talking about is wireshark.
bja
iptables can also do that
atagar
I said I didn't want to do *unnecessary* calls to netstat :)
or tcpdump
overkill - don't need to know anything about the traffic
bja: iptables can be used to query infromation about current network activity?
velope
of course, even netstat wouldn't do that--there could be transient traffic between runs.
iptables in the sense that you implement a firewall with logging and then analyze the logs.
bja
atagar: you can set up rules that will only log or just count the number of packets going through certain ports
atagar
nah, I want to look but not touch (arm has the commandmants of 'thou shalt not log or modify')
bja
not exactly what it was made for but it will do a fast tell tale sign
atagar
too risky that I'll screw up their firewall
seems netstat would be a better indicator (velope is right that it could miss quick, intermittent connections, but should catch most boo boos)
bja
well an iptables-save will output the exact state of their firewall, and then you can run the script after you screwed it up to your needs
atagar: if you run netstat with one second intervals you should not missed most of the conections
atagar
bja: five seconds would be better (average runtime on a non-loaded system is around 30ms... don't want to be a burden on their system)
bja, vegard: great, thanks for the ideas!
bja
Hope they become something usefull :-)
atagar
bja: I'll ping ya for some more after we find out :)
Akira
Hey guys. I was using a private bridge that I obtained in here about 19 days ago... however, as of yesterday it appears to be down. :( I can't fully remember who gave it me. I'm in China, and I guess it would be useful for that person to know that it's now blocked... oh, and if anyone has another IP to try, that would be great too. :) Thank you thank you thank you :)
atagar
Akira: sorry about that... really wish we had better bridge distribution strategies for CN :(
Akira
I'm impressed by China's determination
In the west, the mentality is always that the most determined people will always find a way; so it's useless to try. For example; game piracy. Companies only go so far, because they figure the ones who really want to pirate will do so regardless. but China are being really determined about this
atagar
If they're willing to spend the money to hire armies of people then conventional captcha solutions don't work. Guess we'll need something smarter... got any suggestions?
Akira
Not my area of expertise, the end problem is that if you want your average tor user to be able to figure it out... the g0vernment will figure it out too
atagar
Not necessarily. An example if it, say, takes an hour of work to get an address that might be something a user's willing to do since it'll hopefully stay alive for quite a while. However, a government woulnd't be willing to do that ten thousand times to get all of them.
Akira
You underestimate China, and the cheapness of labour
but yes, that would help
atagar
Akira: If you have ideas then be sure to ping arma. He's been thinking about this problem quite a bit.
Akira
It would be interesting to have some sort of "test" for obtaining a bridge. Like a random trivia question that your average Chinese person wouldn't know
But... with even moderate English skills and Google; you can find out the answer to any trivia
atagar
gonna head home so I'll be afk for a bit
Akira
OK, I'm gonna head back to work too, take it easy - if you find a bridge, lemme know ^_^
abstracted
Thats interesting. so you want to garentee access to a limited resource to the good guys, when the bad guys have as much ore more resources then the sum of the good guys, and are probably better organized.
um, certainly better organized.
web of trust could help. hard to enter for isolated or cut off individuals. easy to sneak into, but unless the adversary owns many nodes in the wot you can effectivly limit the rate of the leak
finite number of IP addresses and ranges is definatly a sticky point.
:(
And even if you had multinational conspiracy and large internet organization, ability to insert/listen on large amounts of traffic in and out of that territory, they may very well opt for isolation.
(very hypothetical of course.)
So in essence, if you were to totally win (easy access to anonymous, uncensored internet for whoever wants it), you would also have lost (certain portions of the globe would self-isolate).
Sebastian_
Goldstein: We've used svn over hidden service and git over Tor successfully. It works quite well.
Sebastian
atagar: won't those plans mean that arm needs root or at least some crazy capabilities?
abstracted
i'm really, really impressed by the speed I am getting.
dandon
yeah. it's been really fast recently
atagar
Sebastian: most people would be running under their standard user which would match most things (firefox, pidgin, etc)
One other idea I'm batting around is whois lookup on the client relays to get the hosting provider or ISP along with the locale. I'd imagine checking for juristictional diversity is something clients would like.
though this runs into the same issue as the reverse dns lookups (ie, potentially leaking the client relays to the exit node)
Sebastian
you can't do that
atagar
for the leaking reason or something else?
Sebastian
yes
atagar
yea, was kinda worried about that... pity
Sebastian
Doing non-torified lookups should be entirely out of the question imo (including for relay mode, you don't know whether it's going to be used as a client) and can't do torified lookups of relays belonging to your circuit either
Goldstein
Sebastian: so you regularly use tor with git/svn when deving?
Sebastian
Goldstein: I use it with git regularly, yes
Goldstein
kooll
Sebastian
works really well
Haven't used the git:// protocol though, only ssh so far
atagar
Sebastian: I agree with the first part for whois, and the second for both (at least not for the first hop, the other two are known to the exit).
Sebastian
atagar: they are known to the exit, but not the exit's whois upstream necessarily
atagar
ah, good point
Sebastian
Even doing that for relay mode is really bad
because you leak stuff to the outside world that they wouldn't otherwise know
atagar
whois? Agreed there
Sebastian
rdns is just the same
atagar
... since the dns providers might not be the same as the relay's hosting. Gotcha.
Sebastian
exactly
atagar
Hmmm... not coming up with a way around this that doesn't require downloading information on every relay out there (obviously out of the question). Damn.
Ok, pie in the sky idea. I host a service that does reverse dns lookups on all relay, and whois lookups distilled down to the information I care about (hoster/isp). Make a nice little tarball and have it be available for arm to fetch (feature off by default - I don't want to get nailed too badly with the bandwidth bill).
For the tiny percentage of people that care about the option and go to the effort of tweaking the config happyness ensues.
Sebastian
I'd carefully evaluate how much data you'd actually push per person
also note that some people might find this interesting even though they don't use arm
« prev 1 2 next »