Is "gatereloaded" a Bad Exit?

[Scott Bennett]

     On Sat, 29 Jan 2011 23:23:55 -0800 Mike Perry <mikeperry at fscked.org>
wrote:
>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.
>>=20
>> 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

     And port 80 is the highest-traffic port.  Exits to port 80 allow
unencrypted access to webmail sites with user ids and passwords transmitted
in the clear.  Using your argument, all nodes allowing exits to port 80
that do not eliminate all webmail sites by way of their exit policies should
be flagged as BadExit.  That would certainly be a strange way to put tor into
the dustbin of computer history, but it would indeed accomplish that.

>waste hours to pinch pennies from their malicious exit policy, they

     gatereloaded is among the top 60 nodes in the network by traffic capacity
and is unlikely therefore to be pinching pennies on it.  It is a valuable
entry and middle node.  If the operator wishes to offer in addition some exit
services for a handful of ports that are unlikely to trigger problems from
the operator's ISP, that is merely added gravy for tor users.

>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.
>>=20
>> 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.
>=20
>> > 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.
>>=20
>> 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

     I second that discomfort.  I further note that the tor project team
has repeatedly claimed that there is an ongoing shortage of exit nodes,
although it has not often noted for which ports there is a shortage.  One
of the selling points for potential exit operators is that the exit operator
can set an exit policy of his/her choice.  The ability to do that means the
operator can evaluate his/her own situation vis-a-vis his/her ISP, data rate
capacity, etc. and decide upon a policy that will not cause him/her a level
of grief unacceptable to him/her.
>
>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.
>
     Here you threaten that the tor project would someday severely reduce
the control that an exit operator would have over his/her node.  How would
such a reduction help to entice more people to run exit nodes?  How would
such a reduction not cause at least some existing exit operators to stop
offering exit services because they could no longer set an exit policy that
they found acceptable in their circumstances?


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/