Re: [tor-talk] Is "gatereloaded" a Bad Exit?

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

On Tue, Feb 22, 2011 at 3:49 PM, thecarp <thecarp@xxxxxxxxx> wrote:
> It is even possible that someone might run tor in lieu of encrypted
> services, I know I went and made sure that the whole trick of getting
> end-to-end encryption by having a node ON the target hosts worked for me.

For that you need an exit policy to yourself, not to the internet.

> I have to wonder, how is that so much worst than the situation anywhere else?

I suggest an alternative question: How much better is it having more
nodes choose not to exclude 443 so that tor will have more 443
capacity, providing faster 443 service and fewer reasons for people to
use unsecured http?

How does that compare to the potential harm of throwing out a near
zero number of nodes with high suspect policies (which are probably
either misconfigurated _or_ are sniffing) and which were not
previously taking considerable exit traffic in any case? Certainly
there are other bad nodes out there, but that doesn't really make it
any better.

It's a small benefit in each direction.  "An incentive for more people
to offer 443" vs "a small amount of additional probably tainted
capacity".  Sensible people might go either way. What sensible people
won't do is participate in an epic argument about it (and I apologize
for my participation)â

Of course, until you factor in the information we received later which
is that a researcher has apparently been using a technique to discover
"passively" eavesdropping nodes, and the node in question here came
up. Sort of mooting the whole discussion until the research is
published.

[snip]
> I am thinking, what if badexits became more like a DNS RBL.... there
> could be multiple sources of truth that people could choose to subscribe
> to. Maybe, for some reason, I feel the need to avoid exits in some area
> (like china), it would allow me to subscribe to the list that tries to
> keep chineese exits banned.

There is already support for geographic targeting in the tor software, fwiw.

> Maybe someone could make a little side cash (bitcoins?) doing node
> contact verification and publishing a badexits list based on faile
> docntact info. Shit...maybe implement a "good exits" for them. Just some
> thoughts. No reason that this needs to be overly centralized.

It's been a long thread so I can understand why you've missed itâ but
there is an _enormous_ smoking gun reason on why this should be to be
somewhat centralized.

Consider: What is more anonymous: two anonymity networks each with one
user or one anonymity network with two users?   The first has no
anonymity at all, the latter has a little.  This pattern plays out
with larger numbers.

If you can split up the users of a anonymity network you make it less
anonymous.  This is a called a partitioning attack.

If you have user selected exit subsets then you are partitioning the
network and reducing its anonymity.

It's especially bad if you know in advance who is in which subset,
E.g. "I told everyone except bob this exit was bad, so if someone is
using it it's probably bob",  but it's can be a bad attack blind  e.g.
 "Mystery person X uses exits 1,2,3 but never 4,5,6,  and
thecarp@xxxxxxxxx also uses the same mixture. I bet mystery person X
is the same persona as thecarp"

Of course, users will sometimes do things which distinguish themselves
but the software ought not _encourage_ anonymity weakening behavior
like this especially when the implications are subtle and not the
practical effect is not especially well understood.  It would be very
sad if someone thought "I need to be extra secure, so I'll turn all
these knobs" and by the resulting unique mix of exits used they ended
up uniquely identifying their client.

So ideally the default behavior should be as broadly acceptable as
possible, and then people who need different behavior should be able
to do so thought hopefully minimum changes which result in the least
anonymity loss. (And hopefully not without understanding the increased
risk that they're taking)
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk