Re: Reusing Exit Nodes?

[Mike Perry <mikepery@xxxxxxxxxx>]

Thus spake Roger Dingledine (arma@xxxxxxx):

> The "mapaddress" functionality is aimed to solve a number of situations:
> 
> 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,
> return a fake address like 0.x.y.z, and then inform Tor via the Control
> interface that 0.x.y.z should map to the string she asked to resolve.

Is there a particular reason why this is more desirable than just
having gethostbyname do the work of tor-resolve?

> 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
> applications can connect to it like normal and get end-to-end encryption
> and auth for free. Second, we don't break applications that include the
> destination address in the application-level. The HTTP "Host" header
> is a good example of this -- if you type www.google.com.rodos.exit in
> your Mozilla, then you break Google's virthosting because it only does
> its geodns magic if you say Host: www.google.com. The alternative is to
> write an application-level-aware proxy that rewrites the Host: line; yuck.

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

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

> > Attached are patches against both 0.0.9.3 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? 

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs