Re: Is "gatereloaded" a Bad Exit?

[grarpamp <grarpamp@xxxxxxxxx>]

> I never made the claim this was safer.

Of course, not quoted as such. Plaintext anywhere is risky. Yet
this entire thread is about sniffing. How plaintext-only exits
somehow equate to sniffing. And how badexiting plaintext-only exits
somehow equates to reducing that risk. Both are weak premises. And
said exits were loosely defined as wolves whose only purpose was
to log traffic.

> I cited several engineering reasosn why this type of exit policy
> is a pain for us.

Perhaps after the nodes were waxed on the premise of sniffing and
the thread exploded. (Dethreading might show otherwise so no picking
is intended at all.) It shouldn't matter though as certainly folks
would better support decisions to solve anonymity engineering and/or
performance problems that are causing a non-trivial impact or holdup.

Is Tor really at the point where reducing the exit matrix provides
significant or greater win as opposed to updates in other areas?

Does (or will) Tor bundle 80+443 to the same destination via the
same exit? What about http[s], smtp[s], imap[s], pop[s], submission
grouping? If the user is using different functions or accounts with
different protocols, he likely doesn't want this. Better let him
do his own bundling with MAPADDRESS or some toggles or something
and enhance those tools instead.

> I've also made the claim that there is no rational reason to
> operate an exit in this fashion

People are encouraged to help out however they can. Therefore,
operator fiat and whim is, by definition, sufficient reason. If Joe
operator thinks 6667, 31337, 21, 23, 25, 80, 6969, 12345, 7, 53,
79, 2401, 19, 70, 110, 123 and so on are pretty uber cool, daresay
even silly motivation, and wants to support them, that's his right.
Just as he can disallow www.{un.int,aclu.org}:80. He doesn't have
to announce it with some 'no sniffing, pro rights' policy statement
to those that might believe the paper it's printed on, validate his
social ties, be contacted, or otherwise vetted.

If another example is needed, not that one is; Corporate, edu and
other LAN's sometimes think they can block 'ooo, encryption bad'
ports so they can watch their user's plaintext URL's with their
substandard vendor nanny watch tool of the day. All the while their
staff laughs at them as they happily tunnel whatever they want over
that (perhaps even the client or exit parts of Tor). Yes, this kind
of joke exists :)

And another; In some equally crazy backwards braindead jurisdiction,
being able to say 'hey, we're not hiding our traffic in crypto, we
forbid it, so look mr. authorized gov agent, you can sniff all that
traffic you're getting reports about, and we're not in it, therefore
we're off the hook'. Perhaps even in France, etc, with their strange
crypto laws.

There was also mention of exits to RFC1918 space. No ISP with brains
routes this, especially not for customer facing interfaces. Yet
they could simply be exits so that the operator and others can
access the 1918 space said operator has deployed internally. They
might not care to use a (hidden service OnionCat VPN) for this. Be
it due to config, speed, anonymity or otherwise. Nor might they
wish to overload routable address space as an exit to their local
designs. It's just as crazy. But they're all rational in someone's
mind.

[I haven't actually tried to map 1918 _in_ to Tor yet, just figured
what can be configured not to go out must be capable of going in.]

What about the users that want to reach their peer, via that only
exit in Siberia whose IP isn't blocked before their peer, that only
happens to only be offering port 80, to which their peer can listen.

It's not a question of whether *we* would do such things or see
them as rational. This is network space, any to any, hack to hack.
One man's widget is another man's stinky wicket. It's the tools
that matter. Tor is a network tool, with a nifty anonymity layer.


>> We also detect throttling by virtue of our bw authorities measuring
>> using 443.
> The same goes for exits that we detect ... throttling 443

Thanks, I yield this hack to be mooted by the project, cool.

> 443 is the second-most trafficed port by byte on the Tor network,
> occupying only ~1% of the traffic.

Sniffing was needed to determine this :) And, assuming 80 was found
to be the first-most (which sounds right); then in the 80+443(+rest)
case, a sniffer's cost is only raised, say, sub 10%, not double.
So dropping said nodes truly does nothing useful costwise either.
(A days worth of netflow on a faster open exit would show the port
distribution breakdown, if anyone wants to.)


Node testing methodologies are cool. And what can't be proven
beyond that belongs to userland. Engineering is also cool (and
there are some potentially good reasons to normalize exits there,
beyond the crypto/non-crypto port groups to be sure). And all the
various use cases, examples and whims are cool. So why not start
a new thread exploring the engineering and, if valid and overriding
of same, let the exit policies fall prey to that instead. That's
just my lay opinion. Anyways, that's all. Party on :)


> I suggest you create some dummy accounts, send your password
> through all exit nodes individually and see which of your accounts
> are accessed.

This requires a number of accounts equal to the number of exits.
You can even get the plausible sample set of usernames and passwords
to use via sniffing :) This testing idea is perhaps one of few
morsels of win to come out of this thread :)
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/