[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Reusing Exit Nodes?

On Thu, Jan 27, 2005 at 12:00:26PM -0600, Mike Perry wrote:
> > a) Alice wants to use a .onion or .exit address from a client that doesn't
> > speak socks4a. For example, we can intercept her gethostbyname() call,
> Is there a particular reason why this is more desirable than just
> having gethostbyname do the work of tor-resolve?

When I ask you to resolve 6sxoyfb3h2nvok2d.onion, what IP does this
resolve to?

These special addresses are not in the 'normal' namespace, so we have to
deal with them some other way.

> > b) Poor man's VPN. Let's say Alice runs a service somewhere that doesn't
> > have encryption or authentication -- like telnet. She can set up a
> > hidden service via Tor to let people connect and get encryption and
> > authentication, but connections to it will require the extra hassle of
> > hidden service foo. So instead she runs a Tor server on the same host
> > (or inside the trusted perimeter of the host), and she configures an
> > Address Mapping to internally rewrite any request for service.com to
> > service.com.aliceserver.exit. This gives two benefits: First, her local

> Is this preferable to RedirectExit because it avoids having to restart
> tor? Otherwise, the functionality is the same, correct?

(I assume you mean 'ExitNodes' -- RedirectExit is something else.)

The functionality between AddressMap and ExitNodes would be nearly the
same -- the difference is that ExitNodes affects *all* streams you make,
whereas AddressMap affects exactly the one you want and not the rest.

(Actually, that's not quite true -- new streams will use whatever open
circuit works, and since you recently built one to the specified exit,
that might be the one that's picked. So it *does* affect others. But
not as strongly.)

(Actually, you wouldn't have to restart Tor to change ExitNodes -- you
could do a SETCONF from the controller to change it, and that would be
all it takes.)

> > c) Inside Tor, mapaddress could do exactly what you're looking for here.
> > If Alice's destination matches certain configured names, or certain ports,
> > then once she picks an exit node it can establish an addressmap so she'll
> > pick it again later.
> > Of course, the controller interface probably needs more data than we
> > describe in the spec, such as an expiry time and maybe more. It would
> > probably make sense to implement the Tor side of things, plus being
> > able to specify it in the Tor config, and then somebody will deal with
> > configuring it via the controller later.
> So in this case it probably wouldn't use the controller protocol at
> all, but instead touch the address mapping data structures directly?

Right. Well, the address mapping data structures should live inside
Tor, since that's where they're used.

Speaking of, you might find our string-keyed binary tree handy in keeping
track of addressmaps and hunting through them, so you don't have to do
it linearly. Check out strmap_* in src/common/container.c

> > > Attached are patches against both and CVS. Please do let me
> > > know if there is something wrong with the patch, I don't mind fixing
> > > it. It seems to work well for me, and I find it useful.
> > 
> > I think what you've got here is a good start, but I think if we
> > generalized it to do mapaddress we'd be in even better shape. What do
> > you think?
> Yeah, once the map address code exists it seems like it would be a
> replacement for the exit_history data structure, at which point about
> half my patch should just go away.. But it looks like a sizeable
> chunk of work though (since it's basically blocked on the entire TC
> and remote). Is there an ETA? 

It doesn't have to block on the controller. You could implement it
locally with normal config options, so people can individually define some
addressmaps when tor starts, and also so people can define some addresses
or ports (as your patch already does) that will get auto-addressmapped
once they pick an exit. Then the controller stuff could come later.

What do you think? :)