Re: path selection despite exit policies

[Roger Dingledine <arma@mit.edu>]

On Tue, Apr 08, 2003 at 10:28:56AM +0100, Andrei Serjantov wrote:
> Can we not publish our exit blacklist somewhere? And ask the node
> operators to keep it fairly uniform (I think conflicts on blocking
> particular sites are unlikely). The entire problem then goes away -- if it
> is blocked on one node, it is likely to be blocked on all (most).

Well, the idea is to let each node operator decide what he's comfortable
with. Some reasons why this might be useful:

* I could run an onion router which would deliver mail to mit.edu
addresses, but not the rest of the world. That is, I'd accept *.mit.edu:25
and then reject *:25.

* I also in particular would like to disallow connecting to localhost:25,
because my mail server is configured to trust connections from localhost.
I don't want to turn myself into an open relay, but I wouldn't want to
prevent Lucky from allowing outgoing 25.

* Some operators may be ok connecting to (eg) port 139 or arbitrary
machines, whereas others don't want to get angry complaints from ISPs
about how they've broken into customer's machines. But I can see a
legitimate use for connecting to port 139 of some public Windows server,
and who are we to say that all tor operators must disallow it?

On the other hand, offering rare services is an excellent way
to draw users into doing something that you can monitor better
\cite{mixminion}. But I don't think that's a strong enough vulnerability
to mean we should undermine usability. After all, I'd like to be willing
to run an onion router on moria, and I basically plan to accept 80,
8080, 443, and 22, and reject the rest.

I hadn't even thought about a blacklist based on sites that say "quit
it".  It seems harder to do that than with Mixminion, because when moria
connects to a random port on the victim's machine, there's no way to say
"this was an onion router, not Roger, here's how you sign up to not have
it happen again". Any thoughts on how to resolve that?

--Roger