Re: all traffic through a VPN on top of tor, done!

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Fri, Nov 13, 2009 at 04:28:20PM +0000, John Case wrote:
>
> On Fri, 13 Nov 2009, Andrew Lewman wrote:
>
>> Second, it sounds like you want to protect against a local attacker from
>> seeing your traffic.  If so, go to proxy.org, find an https:// or
>> vpn-based provider and enjoy your encrypted protection against your
>> local ISP seeing your destination.
>>
>> If you actually want anonymity, then use Tor as is, for it's designed to
>> provide anonymity online by default.
>
>
> Yes, but back to my thread hijack :)
>
> Let's say my protection model does indeed require Tor, but at the same time 
> requires "more" speed.
>
> Forcing Tor to only use fast nodes probably doesn't work, since those fast 
> nodes are probably inundated just like the slow ones are.  This also 
> suggests that organic growth in the Tor network is not going to solve much 
> of the speed problem in the near term...  existing users will certainly use 
> more and more traffic.
>
> But lets say one sets up X Tor nodes in X different locales and configure 
> my Tor to use one of those X for my entry, and one of those X for my exit 
> ... I'm still throttled by my middle hop, but the odds are much higher in 
> my favor, and I may only need to rebuild my connection once or twice to get 
> an acceptable speed.

Ignoring what the underlying network can observe, the value to having
three hops is that the first and last ones don't know about each other
directly (so immediately know who to attack to completely deanonymize
a connection; they instead need to iterate such an attack). But if you
enter and leave the network via nodes you control, the only thing you
are getting from adding a "public" hop in the middle is a greater
chance of an adversary observing you. The problem with your design is
that if anyone discovers the nodes are under your control, then things
emerging from/entering them will be suspected of being associated with
you. (It was similar considerations that led us to recommend even in
the onion routing designs that predated Tor that the network not just
be run by/for the DoD.) Worse still, if you add just a middle hop that
is not yours, you make things worse, not better. Any time it is you
going to a destination observed by your adversary and via a middle hop
owned by the adversary, he will be right in guessing the connection is
more likely to be yours than are arbitrary connections through the
network. He will get this without needing to see your entry connection
into the network.

>
> The question is, what values of X are required in order for correlation, 
> etc., to not be laughable ?
>
> (the assumption here is that I put my X Tor nodes on the actual Tor 
> network, but reserve some percentage of their bandwidth exclusively for my 
> own use ... so they look and act like actual Tor nodes ...)

These are tricky questions, and we are doing ongoing research about it
now. An initial result we have is not quite to answer this question
but instead to look at how you should do routing to avoid compromised
entry and exit nodes if you trust some nodes more than others and
where the difference in trust and percentage of trusted and untrusted
nodes are input parameters. Published in the IEEE Computer Security
Foundations Symposium, cf.
www.cs.yale.edu/~amj37/publications/trusted_sets-csf09.pdf

I think I will have a better, but not complete answer, to questions
closer to yours within several months. But it will involve some
complicated analysis. For now, I suggest you follow Andrew's
advice---or just take your risk if speed matters more than security
for you. But know then that you are entering uncharted and especially
ill-understood waters and that any guesses you might have for X (or
even that this is the right question) are likely to be wrong, and you
really will have no idea what kind of protection you are getting.

HTH,
Paul
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/