client bug in 0.2.2.7-alpha and a new bad exit: exoassist

[Scott Bennett]

     On Wed, 3 Feb 2010 17:16:26 -0500 grarpamp <grarpamp at gmail.com> wrote:
>> passed the name to the exit node for SOCKS name-to-address resolution
>
>Oh, I see, I missed that. For a sec I was thinking it was httpd
>griping about Host:.
>
>> b) "exoassist" is a bad exit that inserts a web page into the stream returned
>> to the client when a connection cannot be made.
>
>>  >That site is in Australia. And considering that that url is down right
>>  >now, and that they're fronting it with squid, who knows what all's
>>  >pooched on their end. Before declaring exo hosed, try it when they're
>>  >back up and by using mapaddress instead.
>
>>  problem is visible when the destination is down.  exoassist is indeed
>>  a bad exit.  It should be flagged as such, but still is *not* flagged.
>
>I don't think this is either a) the case or b) if so, all that
>troublesome to warrant
>a flag. That squid proxy is in AU, either resident on, or in the path
>between, exo
>and fibr. Exo certainly has the right to run a cache, hell, lots of people's own
>upstream ISP's do, transparently. And whoever it is is clearly not munging crap
>with exploits, just throwing a valid error page. Test Exo with one down and one

     The rule has been that an exit that alters the data stream is a bad exit.
To the best of my knowledge, the developers have not publicly stated any
change to that rule.  IIRC, in past discussions of such matters, there have
been cogent arguments presented by others on this list in support of that
policy, even when the alterations to the data stream by a particular exit
seem on the surface to be innocuous.

>up site, preferably both not in AU. Separately from that, if it isn't
>Exo running
>the cache, which from the hostname it appears it's not, then it's not even Exo's
>fault. Further, Exo has a contact listed, so why not ask them first
>before declaring
>them lame.

     tor exit operators are responsible for knowing the rules.  I may send
him a note, but "exoassist" **should already have been flagged** as a BadExit
days ago after my initial posting in this thread.  The flag should be removed
when the operator reports to the directory authority operators that he has
taken care of the problem.  It should not be removed before that has happened
and been confirmed by the authority operators.  Flagging bad exits as soon as
they are noticed is important because it gets the information out to all
clients within a couple of hours, including all those good folks out there
who are *not* subscribed to this list, so that they won't use those exits.
     Given the length of time that has passed since I first exposed the
behavior of the "exoassist" exit node, I would now like to know why, in this
particular case, the directory authorities have not yet flagged "exoassist"
as a BadExit.
>
>Tor needs bandwidth, and I'd happily take it through a well configured Squid :)

     I don't think that security breaches should be allowed or disallowed on
the basis of data relay capacities, so I reject your approach.  Having made
that point, I'll note here that "exoassist" is currently advertising 20 KB/s
with a burst rate of 30 KB/s, so it is not like we would be cutting blutmagie
out of exit service.


                                  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/