well, that mail worked. maybe i'll try ten more.

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}

sebastian: is nsa double-posting each of my commits? sure looks like it

ywo armas?

arma: with way different message. sure there werent two mails sent?

it does look like it.

looks like 2 different styles of commit message script actually

I'll look into it in a bit

where the second seems to be a pretty sucky script. bad timestamps, useless "branch numbering", missing realnme

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.

1/9
on merges, usually.

How is that useless?

pretty useless here. imo. (pretty useless ever, imo)
irrelevant

it gives an order to the commits.

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

depends whether you want timestamp of push or timestamp of commit.
Ganneff: this is actually what people wanted.

well. i pity them, its crap compared to the old. but what do i care, not that i do much for tor :)

ganneff: i actually like having the order on them. otherwise they get dumped into my mailbox and show up in random order.

arma: sort it by date :)

i sort my tor mailbox by date of mail arrived
is there a mutt sort-by-commit-timestamp-inside-the-mail option?

anyways, as i said - i think the second format as seen above is crap, but my opinion simply doesnt count, do what you want

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

pcand: how far have you gotten?
https://www.torproject.org/docs/tor-doc-relay

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?

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. :)

Here, is it better to ask permission to /msg or better to just do it?

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?

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/

arma: Just wondering. If there is something so earth shattering, they should just email you and encrypt it with you public key, I guess.

yep

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 . ?

Pcand: ExitNodes {ip/fingerprint/name/countrycode}
Otherwise, yes.
(+-)

can IP be spoofed?

aah, alright thx dr|z3d

BarkerJr: Sure. Ever heard of the smurf attack?

dr|z3d: or you can just advertise the addresses you want to termporarily steal.

arp poisoning also.. rigtht.

if you've got accesses to a compromised bgp speaker.

*right

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.

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?

so, fingerprint is really the only secure way to specify ExitNodes

or: phobos committed revision 21415 (/website/trunk): update mirrors.

arma: ping

hey. only slightly here. what's up?

arma: what is your take on rsnader's thesis work?

oh, he has a thesis now?

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 :)

i know the ndss paper.

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

it can probably wait til the dvd

ok
thanks

but, i haven't read it, so :)

ok - you no longer have plausible deniability
so I'll ask again in a couple of weeks ;)

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.

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?

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.

:/

in my opinion. not in theirs. more research remains, clearly. :)

its uneven because it favors high uptime relays?
or why?

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

heh - ok that answers a question I've had for a while
10MB/s as in 80Mbps?

yep

and theirs doesn't have such a safety ceiling
?

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.

how do they pick higher bandwidth relays preferentially if they don't weight them higher?

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

:< - :/

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.

thanks

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.

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

a good question. i think the main concern is fingerprinting the client and then being able to recognize him later.

but if the client is using libunet, and libunet were to do better port randomization, ISN selection, etc

yep

intermediate ORs could drop packets, forcing re-transmits

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

yup

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

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

one end is the tor client
which is the other end?
the webserver? the exit relay?

the webserver
or the exit relay if we rule out tap use

we shouldn't require exit relays to be root

you wouldn't to be root

to have root access ever, is what i mean :}

do it as the tor group
ahh
ok

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

it would have to measured
but you do lose something since the exit node is acting as a proxy

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

that is the trivial case when tunneling over udp

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.

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

yep. worth investigating in both directions.

so v1 would have the exit node as proxy and 1.1 add the option of tap

sounds good

I can understand not making it a requirement

my guess is the bulk of the benefits will come from handling congestion inside the tor network better

just like we'll have to support TLS forever

So how does this all look wrt censorship resistance?

even if that isn't the majority of nodes
Sebastian: we'll have to maintain TLS bridges

It seems that it would hurt if the clients don't look like https anymore

I think the guards will support TLS indefinitely
but even China / Iran might see benefit since internally the Tor network will be mostly DTLS

So when you say guards, you mean bridges?

guard nodes

but how does that make sense?

initially everyone would have to support both
for interop
the guard node is the first hop for non bridge users, right?

yes.
except when it isn't

do censored areas not use guard nodes at all?

like when fetching dir data
if I'm worried that people learn I'm using Tor, I better not use guards

ok
but what I'm saying is
there will be no flag day

sure

so DTLS support will be in addition to what is there now

but no flag day and indefinitely are two different things

ok
then I could foresee a day when guard nodes dropped TLS