Re: Random chaff [was: more work for Grobbages]
I was thinking solely of taps capable of observing user1, user2... usern. If user1 injects 1.21 MB of data on one side, and 1.21 MB of data pops out the other side at injection time + network delay, the users are made. Regardless of whether the observer can see inside the network/crypto or operate in the network. And especially if the net or users are quiet at that time. But if there's chaff present, chaff that is only known to be chaff by the network, or minimally by the recipient and generator, then the game becomes harder. User1 and user2's pipes are always independantly full of cap = ( chaff + wheat). Chaff is requested from the network by the user's node to fill the cap during idle times. The cap could be optional random dynamic, perhaps shrink after some time of no wheat nearing the cap so as to not be needless waste. Users's nodes make [close?] peers just for traffic generation. Tagged and controlled out of band. Involve the client's knowledge that its socks or hidden service ports are generating n kbit/sec of wheat. Middle node link traffic could be similarly managed, albeit without socks/hs knowledge, just bandwidth. Any intelligent cell based clocking or committed rate management within seem very hard when riding on the public internet. So it would just be shoving bits into a hungry mouth until a gag message comes back. Maybe the problem with this idea is that the chaff generation system might not be able to react fast enough when the real wheat travels the pipes. So a 1.21 MB injection might still create some sort of observable ripple at start and end times. The only way it might not is if the pipes are oversubscribed _and_ packet lossy by design, not just having the usual TCP congestion managed slowness. But that would be terrible bad for most user facing applications and stacks. Maybe it is the ripples that need hidden or randomized instead of just filling pipes. If it turns out that correlation attacks are far more difficult than the research community thinks It seems safe to presume that near global passive adversaries exist. And certainly ones cabaple of covering various regions. And that offline processing of the mesh of flow information from them is probably within current capabilities. I'm actually amazed we're not seeing canaries kicking off all over the place. Particularly ones involving exits. The advice to run a relay while using the client seems sound due to whatever free chaff it brings. Who knows. Thanks for the links to the anonbib and wiki. I want to read more in the some free time. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Repeatedly changing unique exit nodes
On Thu, Sep 24, 2009 at 10:08 AM, Roger Dingledine a...@mit.edu wrote: On Thu, Sep 24, 2009 at 09:02:05AM +0200, László Monda wrote: I'd like to change exit nodes in every n secs in a way that I don't want the same exit node to be repeated within m secs. You want to do non-standard things with your Tor. You should start by looking at the control protocol specification, which lets you tell Tor how to choose its paths: https://git.torproject.org/checkout/tor/master/doc/spec/control-spec.txt and Torctl, a Python lib to help use the control protocol: https://svn.torproject.org/svn/torflow/trunk/README However, it won't be trivial. Mostly I hear requests like these from people who only know a little bit of php, and they want to vote a thousand times on some online survey, or spam a thousand website comment fields, or other things like that. I have to say I'm not very sympathetic to those goals. Perhaps you have a use case in mind that would make people more excited to see this happen? :) I certainly know more than a little bit of PHP and I have no evil purposes in my mind, but I'm not sure I wanna dwelve this deep into Tor. Thanks for the links though, they're interesting reads. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- Laci http://monda.hu *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT]RE: Unsubscribe
Hi Roger! On Thu, 24 Sep 2009 01:34:19 -0400, Roger Dingledine a...@mit.edu wrote: I just hacked^Wconfigured majordomo to put a footer on every mail to the list. We'll see if it works. While you are at it maybe you can also fix something to eliminate duplicate mails in the list? Sometimes there are series of mails addressed like this: To: or-talk@freehaven.net Cc: or-t...@seul.org which go through the list twice. When subscribing everything talks about seul.org, e.g. majordomo is at seul.org and confirmation mail reads: Someone (possibly you) has requested that your email address be added to or deleted from the mailing list or-t...@seul.org. But then mails from the list contain: Reply-To: or-talk@freehaven.net Maybe just replace or-talk@freehaven.net by or-t...@seul.org here? Alexander Cherepanov *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: private vs. public tor network ... any other options ?
On the other hand, I do control a fair amount of infrastructure and bandwidth in multiple locations ... so it's very tempting to leverage those resources in a way that gives me tor-like anonymity, but without the (sometimes terrible) speed and latency. If you limit yourself to a small set of nodes, you will definitely compromise your anonymity against a powerful attacker. But what if you're not worried about a powerful attacker, or serious anonymity? What if you just want a casual observer to think you're using Tor, and leave it at that? Is there a middle ground ? Is it possible for me to simultaneously contribute network resources to the public Tor network, allowing me to blend in like every other Tor user, yet at the same time somehow leveraging the specific resources I control to achieve faster speeds for my own use ? You could run two relays on each node you control. One relay would be part of the public tor network, and limit the bandwidth to a (large) fraction of what you have available. One relay would be part of your private tor network and use the rest of the available bandwidth. You'd have to bootstrap your tor network from scratch, and set up an authority, and so on. Then you could run your local tor client on your private network, and have a small set of fast nodes available to you. A casual observer at either end (you-hop1 or hop3-internet) would see the traffic from/to a tor node, and assume that it was truly torified. Depending what you personally think the threat profile is - and I'd suggest reading some of the research to find out what threats to consider - you might want to use an entry point or exit node on the regular network, or do other circuit manipulation. Note that trying to take advantage of your own resources inevitably limits your anonymity potential. Customizing your network also means that you won't benefit as much, or at all, from upgrades to Tor. However, if all you want is casually anonymous browsing at high speed, this may be useful to you. Nonetheless, I make no guarantees that the system you set up will be sufficiently anonymous for you.
Re: Random chaff [was: more work for Grobbages]
On Wed, Sep 23, 2009 at 11:12:07AM -0700, Jon McLachlan wrote: *sigh* See below :) I did, but I don't get the sigh. On Sep 23, 2009, at 8:29 AM, Paul Syverson wrote: On Wed, Sep 23, 2009 at 11:11:29AM -0400, Praedor Atrebates wrote: It would appear that the tor network should include some timing randomization and reordering of packets to thwart such analysis. Not so much to really slow things down but enough to throw up uncertainty in the packet analyses. You're trying to turn it into a mix network. That's something that exists in that box over there, not Tor's box ;) I was trying to succinctly say that this is a component of a different system architecture with different assumptions. In the second generation onion routing system we developed, i.e., the one before Tor, we actually included mixing for experimental purposes. The lessons so far has been that it isn't worth it and we did not bother to put that in Tor. That could change, but so far there are no positive indications from the research. The order uncertainty doesn't matter at this level of latency. AKA, as little of latency as possible... which is still quite a bit actually, thank you bittorrent :( The Bauer et al. research I mentioned showed how to do timing attacks based just on setting up the circuit. You don't even need to send any data. *shrugs* If all clients in the network created Tor circuits of the same length, all at the same time, wouldn't that mangle that analysis of who's telescoping circuit-extension request is who's? I know that's not what cover traffic does... but if Tor has some sort of heart beat that would make it more difficult to distinguish between which circuit-extension request is who's... that's only feasible because all clients have a stake in circuits, not the same for external-to-to requests, like webpages etc etc... Yes of course. You say that like it's trivial (to design, implement, etc.) rather than huge. Plus, keeping the existing network nodes synched even just to the point that things don't actually break has not been 100 percent successful, and this would imply much tighter synchronization not just across the nodes but across all the clients as well. And the synchronization is not just to keep things running but now becomes security-critical. Wah! More importantly, it is trivial to beat this with an active attack. Just delay circuit setup packets slightly and watch for the pattern at the other end. Or if the circuit is established, stomp some bits at one end and see if the other end has junk come out shortly thereafter. I'm not saying it's forever hopeless. The things I've mentioned and more have been considered and people have design and evaluated countermeasures to them and continue to do so. As Nick said, the problem isn't that padding doesn't work. It's that it doesn't work nearly well enough (at least so far). Whatever solution (if one even exists) is out there, most of the straightforward ideas and many of the not so straightforward ideas have already been extensively researched. But not necessarily tested in the wild... Even the Bauer et al. demonstrates those ideas in a fake Tor network, yes, on recommendation from Tor not to do the experiment in Tor, but still. And on PL, the VM environment is particularly prone to latency, so of course timing analysis attacks will stick out like a sore thumb... Ermm. The stuff that Lasse and I did _was_ on the deployed Tor network. Now that is not today's network. The network then was much smaller, it didn't have guard nodes, etc. Testing in the wild in general is very tricky because Tor _is_ an operational network, and you don't want to do anything that would inadvertently create problems. This is also an ongoing research challenge. We would like to understand and improve performance by gathering data but without doing anything to increase risk to users or operators. Karsten and others have been working on that. so there might actually be something to deploying that exp on the real network... Yes. There might be. But you would first have to justify the overhead cost to the network by giving at least some reasonable argument that it might work reasonably well, at least better than anything that's been considered to date. Hey we don't know this won't work unless we try, is not an adequate justification. Vetting ideas through the research community seems like a reasonable first step. You would also have to adequately analyze the impact on client and relay performance and security before deploying. Again, nobody's discouraging research into these questions. They just want answers before deploying. So far none of the research has been giving encouraging answers. Cf. what does that mean? :) Sorry. I thought that was standard. It means 'Cf.' means _confer_, i.e., see here. Woops, i.e. stands for 'id est' which means _that is_. HTH, Paul
Re: private vs. public tor network ... any other options ?
We run a private Tor-based network. Email Steve (sms@) or I for questions. What we have contemplated is operating the exit nodes, and mixing into the public Tor network for either the middle or both middle and entry nodes. You could select high bandwidth middle-nodes for this, which would give you reasonably high performance, yet you would have 1-2-or more public nodes in between the user and the exit node. This would provide increased anonymity, while preserving performance and security of the exit nodes (protecting against mal-nodes). The thought was also to select those middle nodes based on measured performance. Thoughts? DJ -Original Message- From: Flamsmark flamsm...@gmail.com Date: Thu, 24 Sep 2009 11:24:27 To: or-talk@freehaven.net Subject: Re: private vs. public tor network ... any other options ? On the other hand, I do control a fair amount of infrastructure and bandwidth in multiple locations ... so it's very tempting to leverage those resources in a way that gives me tor-like anonymity, but without the (sometimes terrible) speed and latency. If you limit yourself to a small set of nodes, you will definitely compromise your anonymity against a powerful attacker. But what if you're not worried about a powerful attacker, or serious anonymity? What if you just want a casual observer to think you're using Tor, and leave it at that? Is there a middle ground ? Is it possible for me to simultaneously contribute network resources to the public Tor network, allowing me to blend in like every other Tor user, yet at the same time somehow leveraging the specific resources I control to achieve faster speeds for my own use ? You could run two relays on each node you control. One relay would be part of the public tor network, and limit the bandwidth to a (large) fraction of what you have available. One relay would be part of your private tor network and use the rest of the available bandwidth. You'd have to bootstrap your tor network from scratch, and set up an authority, and so on. Then you could run your local tor client on your private network, and have a small set of fast nodes available to you. A casual observer at either end (you-hop1 or hop3-internet) would see the traffic from/to a tor node, and assume that it was truly torified. Depending what you personally think the threat profile is - and I'd suggest reading some of the research to find out what threats to consider - you might want to use an entry point or exit node on the regular network, or do other circuit manipulation. Note that trying to take advantage of your own resources inevitably limits your anonymity potential. Customizing your network also means that you won't benefit as much, or at all, from upgrades to Tor. However, if all you want is casually anonymous browsing at high speed, this may be useful to you. Nonetheless, I make no guarantees that the system you set up will be sufficiently anonymous for you.
Re: [OT]RE: Unsubscribe
grarpamp wrote: [...] they knew they had to find and use some special interface to subscribe. So why in the world would they think unsubscribing is any different having already learned the former. The thing is, sending a message like the one we saw does, practically always, achieve the desired result. Sometimes it leaves remaining subscribers discussing mailing list software and the like, but the main thing (from the unsubscriber's point of view) is that it does work. If it doesn't work you just send another one. Pretty soon you find yourself unsubscribed ;) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: private vs. public tor network ... any other options ?
Hello David, On Thu, 24 Sep 2009, David Jevans wrote: What we have contemplated is operating the exit nodes, and mixing into the public Tor network for either the middle or both middle and entry nodes. You could select high bandwidth middle-nodes for this, which would give you reasonably high performance, yet you would have 1-2-or more public nodes in between the user and the exit node. This would provide increased anonymity, while preserving performance and security of the exit nodes (protecting against mal-nodes). The thought was also to select those middle nodes based on measured performance. Thank you - that does help. So you are always using your own exit nodes, and usually using public Tor for hops 1 and 2, but sometimes using yourself for entry ? What makes the determination, for you, whether to use two public Tor hops vs. just one (the middle) ? I suppose a converse of this is that you could put private nodes in your route so as to run your traffic over four or five hops (instead of the default three) without the typical speed/latency costs. So, increased speed for three hops, or no speed loss for 3+X hops... But that still leaves the undefined anonymity loss, which appears to be non-zero... Thanks again - any additional comments you may have are appreciated. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: private vs. public tor network ... any other options ?
On Thu, 24 Sep 2009, Flamsmark wrote: On Thu, 24 Sep 2009, Flamsmark wrote: If you limit yourself to a small set of nodes, you will definitely compromise your anonymity against a powerful attacker. But What would you (loosely) define as a small set of nodes vs. a large set of nodes ? You want as many nodes as you can get. How many have you got? Well ... let's say I have 6 nodes. That's a very small number. But then let's say that all six nodes are in quad-homed datacenters where I can get one (or more) IPs on each peer. So now, assuming I run one VM per network, I've got 24 nodes, each on a different route on the Internet. 6 is low. I suspect 24 is low. But is it laughably low ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Some misc. exit node questions ...
First, am I to understand that this list is referring specifically to ISPs that allow exit nodes ? Presumably a relay node is not deteted and your ISP does not care ... https://wiki.torproject.org/noreply/TheOnionRouter/GoodBadISPs One problem with this list, however, is that it deals mostly with residential, end-user Internet connectivity, while I would think that IP transit service, or co-located service (or even VPS) would be much more useful to the Tor network. Other than the reasonably good notes on rackspace, are there any other exit-node-friendly providers that are providing something more than a home cable/dsl connection ? I wonder specifically about he.net, as I consider their ipv6 tunneling, and the running of the lightning.net irc server as very clueful and abuse-tolerant activities... Second, what is the bandwidth (a)symmetry of an exit node ? As it is an _exit_ node, I am assuming that a very large ratio of the traffic is outbound traffic. However, I understand that just because a node is an exit node does not mean it cannot be chosen at any given time as either an entry node or a relay node, and therefore the traffic should become more symmetric. So, if I run a fairly stock/standard exit node configuration, what percentage of my traffic will be outbound ? Finally, any comments on running an exit node for only ports 22,80,443 ? These are the only ports I ever use, and the absence of port 25 and 6667 certainly removes a large amount of abuse ... if I throw a lot of bandwidth at exit nodes doing only those three ports, will that be a noticeable boost to the Tor network, or do people need more flexibility than that ? Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
