Is "gatereloaded" a Bad Exit?
Mike Perry
mikeperry at fscked.org
Sun Jan 30 07:23:55 UTC 2011
Thus spake Eddie Cornejo (cornejo at gmail.com):
> > I believe that allowing these nodes sends a message that we are OK
> > with people monitoring plaintext traffic, because it is anonymized. We
> > have never been OK with this.
>
> Ok, I accept that this might send a message to 50ish nodes (if you ban
> all 50+) but if someone was so inclined they could still do this by
> allowing encrypted traffic and throttling it/blocking it outside of
> TOR (transparent proxy perhaps?) I predict this is worse as the user
> client will believe node A will honestly relay encrypted traffic and
> will select it on this basis, only to find their connection is slow or
> doesn't fully connect. Admitedly, this won't be a huge problem unless
> a good number of nodes started doing this.
We can detect nodes that fail encrypted connections. We currently scan
for failure of port 443. We also detect throttling by virtue of our bw
authorities measuring using 443.
443 is the second-most trafficed port by byte on the Tor network,
occupying only ~1% of the traffic. If stingy exit nodes really want to
waste hours to pinch pennies from their malicious exit policy, they
can try crafting a throttling policy that we can't detect. Seems like
there are better ways to spend their time. Like reading other people's
email.
So no, I'm not terribly concerned about second-order effects of this.
> > People use plaintext at their own risk, and yes, they should know
> > better, but this does NOT mean that we are comfortable feeding them to
> > the wolves.
>
> My argument is that you're not identifying wolves. If you were serious
> about identifying wolves then could I suggest you create some dummy
> accounts, send your password through all exit nodes individually and
> see which of your accounts are accessed. This would positively
> identify wolves. All you're achieving by soley looking at exit
> policies is identifying things that may or may not be wolves and
> ignoring the larger body of exit nodes that may or may not include
> wolves. I submit your testing is flawed.
We're not trying to identify wolves. We are sending a message to the
community.
> > If said exits are really interested in helping, they should alter
> > their exit policy to allow encryption and then rekey. They will be
> > banned by identity key, not by IP. Rekeying without fixing the exit
> > policy will just result in IP bans.
>
> I'm not sure I'm comfortable with dictating how an exit nodes
> exitpolicy should be defined. Each policy should be up to the exit
> node owner to decide. Just my 2c
Not really. In reality, it's up to those who write the code to decide
what is available and how it works ;). Welcome to The Golden Path.
At some point, we intend to shrink exit policies further as Tor scales
to more decentralized schemes. Those exit policies will likely be
represented as bits representing subsets of ports. When that time
comes, we will very likely combine encrypted and unencrypted versions
of ports together, removing this option entirely.
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20110129/5642207e/attachment.pgp>
More information about the tor-talk
mailing list