logs archiveIRC Archive / Oftc / #tor / 2010 / January / 16 / 1
arma
well, that mail worked. maybe i'll try ten more.
nsa
or: Roger Dingledine <arma@torproject.org>: 2010-01-13 04:10:45 [tor/master]: resolve path weighting edge case; fixes bug 1203
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 19:05:12 [tor/master]: trivial cleanups
or: Roger Dingledine <arma@torproject.org>: 2010-01-15 20:55:08 [tor/master]: fix an impossible-to-actually-trigger overflow in descriptor generation
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 17:39:39 [tor/master]: fix some typos in our spec files
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 17:17:07 [tor/master]: don't list windows capabilities in windows uname
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 17:18:08 [tor/master]: don't warn if stats/bridge-stats is missing
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 17:27:37 [tor/master]: man page entries for PerConnBW{Rate,Burst}
or: Roger Dingledine <arma@torproject.org>: 2010-01-12 17:19:49 [tor/master]: remove redundant validate_addr_policies() checks
or: Roger Dingledine <arma@torproject.org>: 2010-01-15 20:58:35 [tor/master]: whitespace fixes
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:03 +0000 (UTC) to tor/master 9/9: whitespace fixes
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:03 +0000 (UTC) to tor/master 8/9: fix an impossible-to-actually-trigger overflow in descriptor generation
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:02 +0000 (UTC) to tor/master 2/9: don't warn if stats/bridge-stats is missing
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:03 +0000 (UTC) to tor/master 6/9: trivial cleanups
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:03 +0000 (UTC) to tor/master 7/9: resolve path weighting edge case; fixes bug 1203
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:02 +0000 (UTC) to tor/master 3/9: remove redundant validate_addr_policies() checks
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:02 +0000 (UTC) to tor/master 1/9: don't list windows capabilities in windows uname
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:02 +0000 (UTC) to tor/master 5/9: fix some typos in our spec files
or: arma@torproject.org committed patch at Fri, 15 Jan 2010 22:35:02 +0000 (UTC) to tor/master 4/9: man page entries for PerConnBW{Rate,Burst}
arma
sebastian: is nsa double-posting each of my commits? sure looks like it
BarkerJr
ywo armas?
Ganneff
arma: with way different message. sure there werent two mails sent?
Sebastian
it does look like it.
Ganneff
looks like 2 different styles of commit message script actually
Sebastian
I'll look into it in a bit
Ganneff
where the second seems to be a pretty sucky script. bad timestamps, useless "branch numbering", missing realnme
         

Sebastian
the missing realname thing actually is the thing we want, because that is the pusher info.
don't know what you mean wrt branch numbering.
Ganneff
1/9
on merges, usually.
Sebastian
How is that useless?
Ganneff
pretty useless here. imo. (pretty useless ever, imo)
irrelevant
Sebastian
it gives an order to the commits.
Ganneff
does a working timestamp also
you dont need the merger/pusher timestamp - you have that. the date the commit message appears (here or in mail). so using the commit timestamp gives the order
Sebastian
depends whether you want timestamp of push or timestamp of commit.
Ganneff: this is actually what people wanted.
Ganneff
well. i pity them, its crap compared to the old. but what do i care, not that i do much for tor :)
arma
ganneff: i actually like having the order on them. otherwise they get dumped into my mailbox and show up in random order.
Ganneff
arma: sort it by date :)
arma
i sort my tor mailbox by date of mail arrived
is there a mutt sort-by-commit-timestamp-inside-the-mail option?
Ganneff
anyways, as i said - i think the second format as seen above is crap, but my opinion simply doesnt count, do what you want
Pcand
okey, i know it's in the FAQ somewhere.. but can't seem to were it is .. i'm want to configure a fixed exit node but can't seem to find where, someone that could pass along the url or something ? hehe
arma
pcand: how far have you gotten?
https://www.torproject.org/docs/tor-doc-relay
Pcand
ehrm well memory is faulty haha
i had once installed it all.. bout a lil over a year ago
but well after reformation and reinstall it's gone and so is my memory :p
arma, mind if i bother you with a PM?
arma
sure. or you could just ask here.
pcand: did the url i pasted not help?
oh. you don't want to run an exit relay. you want to configure your tor to always use the same exit point?
that's a less interesting question. :)
lk
Here, is it better to ask permission to /msg or better to just do it?
Pcand
yah hehe for now .. once my new server is up and running and all that .. THEN it'll be an exit point .. but sadly it's a while till that day .. ehrm anyhow yah , to use same exit point all the time .. any example on what to put in the config?
arma
lk: it's best to just say things out loud, if they're tor related, and not at all if they're not :)
pcand: search the faq for 'exitnodes'. but really, if you're not looking for privacy, you might find one of those sketchy "100% privacy guaranteed" one-hop proxy things.
s/things./things to be more useful for you/
lk
arma: Just wondering. If there is something so earth shattering, they should just email you and encrypt it with you public key, I guess.
         

arma
yep
Pcand
ehrm yah true true but uhm i have an exit node that's in my country and only really need it for a single port due to that my isp somehow have managed to find a block on it .. while their support is claiming they ain't blocking it .. lol
arma, to add an exitnode , is it just to add at the end of the config "ExitNodes ip" and StrictExitNodes 1 . ?
dr|z3d
Pcand: ExitNodes {ip/fingerprint/name/countrycode}
Otherwise, yes.
(+-)
BarkerJr
can IP be spoofed?
Pcand
aah, alright thx dr|z3d
dr|z3d
BarkerJr: Sure. Ever heard of the smurf attack?
murb
dr|z3d: or you can just advertise the addresses you want to termporarily steal.
dr|z3d
arp poisoning also.. rigtht.
murb
if you've got accesses to a compromised bgp speaker.
dr|z3d
*right
murb
you don't want to use your own network, as all updates are logged and have been for *years*
see also riswhois
dr|z3d: spoofing an IP on a LAN is one thing.
anyay this is heading towards -> #nottor.
Pcand
this is what my conf looks as right now, http://pastebin.com/m7892a157 .. but the exit i seem to get is a dutch one and not a swedish one.. suggestions?
BarkerJr
so, fingerprint is really the only secure way to specify ExitNodes
nsa
or: phobos committed revision 21415 (/website/trunk): update mirrors.
j_r
arma: ping
arma
hey. only slightly here. what's up?
j_r
arma: what is your take on rsnader's thesis work?
arma
oh, he has a thesis now?
j_r
http://hatswitch.crhc.uiuc.edu/~rsnader/thesis.pdf
I stumbled on it
the premise is interesting, but I have plenty of other things in my queue
I assumed you'd have read it
guess not :)
arma
i know the ndss paper.
j_r
was looking for the Ebert & Siskel thumbs up / thumbs down
should I see this thesis in theaters or wait until it comes out on dvd
arma
it can probably wait til the dvd
j_r
ok
thanks
arma
but, i haven't read it, so :)
j_r
ok - you no longer have plausible deniability
so I'll ask again in a couple of weeks ;)
arma
the ndss paper was neat. it had a couple of really good ideas. but the other ideas it had i think are wrong. i still need to convince nikita of this.
feel free to ask in a few weeks. these days i don't seem to get anything new done, so a few weeks from now i won't have read it either.
j_r
I think crypto folks have successfully convinced networking folks that crypto is HARD(tm)
I don't think networking folks have made as much of an effort to scare off dilletantes ;)
maybe I'm being arrogant, but a number of the side ideas in reardon's thesis didn't seem well thought out - fortunately the core premise is sound
arma: can you summarize quickly what was good / bad with the ndss paper?
arma
measuring actual bandwidth seen good. passive measurement sounds even neater if you can do it.
problem #1 (potentially minor): if we get n^2 bandwidth reports, are we revealing more about what's going on in the network? "hm"
(right now we only get n)
the part where their idea gets bad is where they say "tor's load balancing is off right now, we measured it and the distribution was uneven. so here's our new load balancing algorithm that is better."
except tor's load balancing was uneven for a different reason than they suspected, and their algorithm is worse.
j_r
:/
arma
in my opinion. not in theirs. more research remains, clearly. :)
j_r
its uneven because it favors high uptime relays?
or why?
arma
it was uneven because it clipped relays at 10MB/s of advertised bandwidth, so they wouldn't get more than a safe share of the traffic
j_r
heh - ok that answers a question I've had for a while
10MB/s as in 80Mbps?
arma
yep
j_r
and theirs doesn't have such a safety ceiling
?
arma
no, theirs is based on lining up all the relays by bandwidth, not weighted but just ordered
and then choosing randomly
really dreadful actually. i don't see how they could have claimed it was better.
j_r
how do they pick higher bandwidth relays preferentially if they don't weight them higher?
arma
they claimed theirs was better because they took the current tor network, where really fast relays were underused, and applied a single tor client using a different algorithm that overused really fast relays, and said "wow our rocks"
read the paper :)
once you've read it, read http://freehaven.net/anonbib/#murdoch-pet2008 for a refutation
j_r
:< - :/
arma
but before you read either of them, read http://blog.torproject.org/blog/torflow-node-capacity-integrity-and-reliability-measurements-hotpets
that one you'll like, i hope. thumbs up.
j_r
thanks
arma
all of that said, i like nikita. he does good stuff. i'm confused about why he likes this design so much. maybe i'm wrong.
j_r
when you have a few more spare cycles I wanted to corner you about end to end TCP and information leakage
I'd like to understand a little bit more how plausible the attacks are if the receiver sees the senders TCP state
arma
a good question. i think the main concern is fingerprinting the client and then being able to recognize him later.
j_r
but if the client is using libunet, and libunet were to do better port randomization, ISN selection, etc
arma
yep
j_r
intermediate ORs could drop packets, forcing re-transmits
arma
really, the first line of concern is distinguishing one tcp stack from another. so if everybody has the same stack, we're off to a good start
j_r
yup
arma
but you make a good point that that may not be sufficient. you can recognize the guy that's made around 11000 connections since he started his tor, vs the guy who's made around 1000
j_r
that can be fixed - but what about collusion between nodes or receiver and a node
I really want the connection to be end to end so that ORs are no longer proxies
arma
one end is the tor client
which is the other end?
the webserver? the exit relay?
j_r
the webserver
or the exit relay if we rule out tap use
arma
we shouldn't require exit relays to be root
j_r
you wouldn't to be root
arma
to have root access ever, is what i mean :}
j_r
do it as the tor group
ahh
ok
arma
it's not a hard requirement. exit relays have tougher problems right now, so it wouldn't be the end of the world.
if we're going to run into worlds of pain by ending our tcp streams on the exit relay, we should reconsider that
but in my happy-land, it would be nice to just have them be a program that a user runs
j_r
it would have to measured
but you do lose something since the exit node is acting as a proxy
arma
camilo's design put a socks proxy on the exit relay, and did end-to-end tcp between the client and the socks proxy on the exit relay
j_r
that is the trivial case when tunneling over udp
arma
yep. in current practice, the bottleneck is inside tor, and the exit relay is limited by its rate limiting. but still, i could see how the congestion inside the network should dictate how much of each stream we allow to go into the network.
j_r
but at the exit relay it has to pump out TCP packets
in general it is desirable to give an application like tor its own sandbox
jail / vserver / container
which would have its own logical interface anyway
so it isn't unreasonable to provide the option
I reeeeeally don't think people running exit nodes are unsophisticated
arma
yep. worth investigating in both directions.
j_r
so v1 would have the exit node as proxy and 1.1 add the option of tap
arma
sounds good
j_r
I can understand not making it a requirement
arma
my guess is the bulk of the benefits will come from handling congestion inside the tor network better
j_r
just like we'll have to support TLS forever
Sebastian
So how does this all look wrt censorship resistance?
j_r
even if that isn't the majority of nodes
Sebastian: we'll have to maintain TLS bridges
Sebastian
It seems that it would hurt if the clients don't look like https anymore
j_r
I think the guards will support TLS indefinitely
but even China / Iran might see benefit since internally the Tor network will be mostly DTLS
Sebastian
So when you say guards, you mean bridges?
j_r
guard nodes
Sebastian
but how does that make sense?
j_r
initially everyone would have to support both
for interop
the guard node is the first hop for non bridge users, right?
Sebastian
yes.
except when it isn't
j_r
do censored areas not use guard nodes at all?
Sebastian
like when fetching dir data
if I'm worried that people learn I'm using Tor, I better not use guards
j_r
ok
but what I'm saying is
there will be no flag day
Sebastian
sure
j_r
so DTLS support will be in addition to what is there now
Sebastian
but no flag day and indefinitely are two different things
j_r
ok
then I could foresee a day when guard nodes dropped TLS
« prev 1 2 3 4 next »