logs archiveIRC Archive / Oftc / #tor / 2010 / January / 7 / 1
kmacy_
arma: http://www.usenix.org/event/usenix06/tech/full_papers/park/park_html/paper.html
jr__
arma: bot detection
deadweight
Is anyone here familiar with those Danasoft.com IP identifiers?
lk
Never heard of it.
deadweight
http://www.danasoft.com/
lk
Oh yeah, I saw one of those today on a forum sig.
Are you the ISP checking up on me? :)
deadweight
Yea, well one of them told me I "Visited a politically incorrect site this week". How would it know this.
what?
no
oops, i meant How would it know this?
lk
I know... It was just an odd coincidence that I saw one a few hours ago, and now see someone here pop in asking about it.
murb
take it to #nottor.
         

jr__
arma: Not that I asked for on, but I take it I wasn't to expect a response from Ian?
phobos
ian is typically busy and takes a few days to respond
something about teaching, grad students, writing OTR, and research
jr__
phobos: professors aren't the only one with full time jobs :D
phobos
I know
jr__
I'm sure I know people who are busier
their interest in responding is a function of my importance to them
anywhere from 1 hour to ... never
phobos
I'm sure this discussion can lead no where productive. I'm just stating ian's typical response patterns.
jr__
your first statement would have sufficed
your second was ...
phobos
ok
waltman
I'd like to mirror directory information. Do I need to do anything other than uncomment "DirPort 9030" in torrc and sent the tor process a HUP?
It logged a message saying 'Opening Directory listener on 0.0.0.0:9030". Is that normal?
Odd. It says "[warn] Your server (207.245.72.170:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc." But I'm able to telnet to that port from outside.
keb
is that the correct ip address of your node
waltman
yes
OK, maybe it was just slow. It just logged "Self-testing indicates your DirPort is reachable from the outside. Excellent."
but then it says it won't advertise it because my bandwidth's below 20k
er, 50k
how big is the directory?
keb
yes
waltman
Anyway, then should I just not bother here and turn it back off?
keb
yep
waltman
ok
keb
unless you have more bandwidth
waltman
sadly no
arma
waltman: you can leave it on or turn it off, tor will handle it either way
waltman: if you leave it on, tor will actually fetch all the dir stuff. it just won't tell clients it's a good place to learn dir info.
so if you want to use the dir info yourself, you should leave it on. otherwise, it doesn't matter. (you can save a bit of bandwidth by turning it off, i guess)
jr__: ian responds better to periodic (like, once or twice a week) followup emails. (i do too i guess.)
Sebastian
jr__ is gone.
arma
jr_ remains
         

Sebastian
ah hey.
arma
he's a sneaky one
hjubal
buongiorno *
arma
(Action) wakes
anonym^
how does outbound port filtering play with Tor? I guess the important part of this question is how filtering might disturb the selection of entry guards.
kc_sebastian
anonym^, are you talking about Tor clients only_
?
anonym^
yup
kc_sebastian
If none of the ports 80, 443, 9001 work, you will have trouble bootstrapping becaus your client cannot contact the authorities. Afterwards, if you've told your Tor about which ports work, it will try to pick guards that will work with your firewall.
If you don't tell Tor, it will pick entry guards at random and might not realize that it could work with a few of them.
anonym^
and how long time will it take for the client to drop an unreachable entry node? and will the client try to reach it later? will the node be blacklisted in some way?
in general, is my assertion correct, that one's anonymity isn't hurt that much by outbound port filtering, but performance might be (especially in the case when you don't explicitly tell Tor which ports are blocked)?
kc_sebastian
I believe that if one of them works, so Tor can realize that its network is not down, it will pick a new one rather soon.
if you don't tell tor which ports are blocked, and common ports (9001, 443, 80) are blocked, your Tor might not work at all.
Your anonymity can be influenced, too:
imagine there is one entry guard with orport 7777, and all other ports are blocked. Then tor will use that one (if it has cached consensus information)
that takes one hop of your path.
arma
anonym^: if the guard is unreachable when you pick it, you'll drop it from the list soon after.
if it was once reachable, and you reached it, and now it's unreachable, it will stay on the list for months just in case.
also, if you say reachableaddresses *:80, which narrows down the choices a lot, and the adversary guesses you said that, he has a lot less work to do to find your entry guards.
(which affects anonymity)
anonym^
sure, but if you have the more common ORPorts reachable, you're not that bad off anonymity-wise, eh?
kc_sebastian
right. there are 15 relays with orport 15
only 7 of them are guards
arma
anonym^: which ports did you have in mind? are you hoping to restrict your livecd's tor client's reachableports with a firewall and also a tor config?
kc_sebastian
almost 100 guards with orport 443.
and more than 200 with orport 9001.
wth, fluxe3 fell out of the network
ah no, it just lost its guard flag.
anonym^
yeah it's 9001 and 443 I'm talking about.
arma: no I'm not trying to set such a restriction. it was just a question I got from one of my users who use outbound port filtering on his network and wants to know how bad it is for him... and I'm not completely sure what to answer
kc_sebastian
He's restricting himself to about 50% of the guards
arma
permitting 443 and 9001 should be ok, if you need to do it
but in my world, outbound filtering is silly
kc_sebastian
anonym^, heh, my numbers were incorrect. We only have 415 guards.
wow, we used to have more.
I guess many relays share fluxe3's fate
arma
the fate that it vanished for no reason from the consensus?
kc_sebastian
no, that it lost its guard flag
I thought it had vanished, but it had simply lost the guard flag.
anonym^
arma: yeah, that's what I said to him, but he has windows machines on his network... I guess his reasoning is that if they are infected with some malware, outbound filtering might prevent them from phoning home or attacking other computers
arma
sebastian: sure enough, only one vote for guard for fluxe3
kc_sebastian
arma, maybe other guards now have a lot more bandwidth
so that fluxe3's bandwidth isn't sufficient anymore
hah
now I now why fluxe3 has not saturated its bandwidth in the last weeks
because it isn't a guard anymore.
arma
Jan 07 08:07:24.728 [info] Cutoffs: For Stable, 153905 sec uptime, 309414 sec MTBF. For Fast: 20480 bytes/sec. For Guard: WFU 97.341%, time-known 670332 sec, and bandwidth 63312 or 73728 bytes/sec. We have enough stability data.
it should have enough bandwidth
kc_sebastian
hm
arma
i guess its mtbf is not good enough
kc_sebastian
probably
I don't restart it often, though. Only when we update alpha packages usually
ah
arma
R ED13D1D13C1E57C6A406DD64551D2F905AB99AFF
+MTBF 13978 0.04960 S=2009-12-18 07:23:00
+WFU 13978 213887
kc_sebastian
it was off for a bit
maybe that's it. I don't know.
arma
i think our whole mtbf calculations are crap
i've thought this periodically. we find a bug and fix it. then time passes. repeat.
kc_sebastian
heh.
arma
waaait
Guard comes from median bandwidth and median wfu
not median mtbf
(Action) readjusts his brain
so in fact, if i'm reading this right, moria1 thinks you've been up 13978 of the last 213887 seconds
depending on what 'weighted' means'
alas, it almost certainly does not mean the simple thing that i hope it means.
actually, based on get_weighted_fractional_uptime(), it does look like it's that simple.
fluxe3 has been up 13978 of the last 213887 seconds, *plus* all the seconds since 2009-12-18
that really ought to give it enough wfu, you'd think.
kc_sebastian
how can fluxe3 be up for 14000 seconds. it has an uptime of 10 days
arma
that was its previous record.
see get_weighted_fractional_uptime() in rephist.c
kc_sebastian
ah
(Action) fetches the tor source. ah wait
ah, gitweb works, true.
arma
tarball works too :)
kc_sebastian
I know where to find the snapshot on gitweb :P
arma
as i understand it, fluxe3 has a wfu of 1309978/1509887 = 86.76%
even though it's been up for like 18 days now
kc_sebastian
right, the real wfu should be much higher
arma
well, the code is doing what it was told, which is a good start
the problem is that our algorithm is wrong. i think because it doesn't handle current runs the way it should.
kc_sebastian
ah
arma
you had a downtime of 2.5 days before this last run?
kc_sebastian
we had that problem before.
hm
I had a longer downtime
the current run is 10 days so far, meaning that would've been end of December
I had a short downtime there
arma
10 days? my tor thinks you've been up since dec 18
kc_sebastian
oh
that's incorrect
arma
whee
kc_sebastian
One of the days when I was feeling oh so well I did an ifdown eth0 on my server
and that was during congress.
10 days ago, to be exact.
I rebooted the machine
downtime about 30 minutes or so
maybe an hour or two, I don't know
arma
in theory moria is supposed to not notice the downtime (it's too short),
but is supposed to notice that the uptime in your descriptor went back a lot, and count that as a downtime
bvg
Hi
arma
hi
bvg
i got a question related to google thinking i'm a bot
kc_sebastian
shoot
arma
yep. i wrote a faq entry about that. it might help.
bvg
i searched the site, but there's about 3 faqs... can you show me a link to your entry?
basically i'm not a bot, and i don't like to be labeled one ;)
arma
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#GoogleSpyware
you might like https://scroogle.com/
bvg
the problem is that other users (not using tor) on the local lan get a "you're a bot" message from google
ie. when accessing a chached search result page
kc_sebastian
arma, except that's a porn site
https://ssl.scroogle.org/ works better.
arma
oops
bvg
i can't tell those users to change their browser, search page, or google habits
arma
well, my statement stands. ;) but sebastian's may be more useful.
bvg
:)
phobos
arma's all about tor for porn, clearly
kc_sebastian
well, https doesn't work there. boo.
arma
hm. one option would be to put reject 64.233.169.0/24:80 in your exit policy
phobos
the latest torbutton 1.2.4 has some attempts to minimize google captchas
arma
that will tell tor clients not to try to go to google through you
phobos
which seem to work well
bvg
but then no tor user can use google via my exit, right?
arma
phobos: right. but the problem here is that the tor exit relay is on the same network as other users, who are punished because they share an ip address with a tor exit relay
phobos
right
arma
bvg: correct
phobos
so use tor
;)
bvg
tor is too slow :(
at least for downloading the average game demo (my main internet usage)
kc_sebastian
I'd tell you to run a relay, but... :-) Thanks for running one!
So the best thing would be to stop exiting to google.
bvg
yeah i got a server running anyway, so i thought "there's no backdraw to this"
seems i was over enthusiastic ;)
arma
bvg: do you happen to have a second ip address you could use for the relay?
bvg
nope
kc_sebastian
it is unfortunate that running a relay doesn't have sideeffects sometimes.
erm
you know what I mean.
bvg
nothign is for free :)
arma
yep. at least you're not an efnet user.
bvg
what's that?
kc_sebastian
an irc network
bvg
and it's evil or what?
arma
yep. a) it has lots of jerks as users, so it attracts more
bvg
a propos evil: is there talk with google about the problems with tor and their spamer heuristic?
arma
b) it blocks tor in a very overbroad way
we've talked to google about it on and off. i think the problem is that there actually *are* people crawling google through tor. mostly people from rival search engine companies, or people trying to do 'search engine optimization'.
bvg
well it's the sensible choice :)
« prev 1 2 next »