PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)

Scott Bennett bennett at cs.niu.edu
Thu Apr 15 07:28:57 UTC 2010


     On Thu, 15 Apr 2010 09:17:39 +0200 Sebastian Hahn <mail at sebastianhahn.net>
wrote:
>On Apr 15, 2010, at 9:11 AM, Scott Bennett wrote:
>
>>     On Thu, 15 Apr 2010 08:25:07 +0200 Sebastian Hahn <mail at sebastianhahn.net 
>> >
>> wrote:
>>> On Apr 15, 2010, at 8:17 AM, Scott Bennett wrote:
>>>> Unfortunate (IMO), the latest versions have the support for .exit
>>>> either disabled or deleted, apparently leaving us no easy way to
>>>> perform
>>>> such tests.  I've asked recently on this list whether some other
>>>> easy way
>>>> were available, but have been met with silence, so I assume that  
>>>> there
>>>> still is none.
>>>
>>> If you want the functionality, feel free to set the AllowDotExit
>>> config option
>>> to 1. Note that this can't be recommended, because it opens you up  
>>> for
>>
>>     That is what I have been doing in order to be able to test for  
>> exit
>> misbehavior.  However, the ChangeLog notes under "Minor bugfixes" for
>> 0.2.2.9-alpha the following:
>>
>> 	- Resume handling .exit hostnames in a special way: originally we
>> 	stripped the .exit part and used the requested exit relay. In
>> 	0.2.2.1-alpha we stopped treating them in any special way, meaning
>> 	if you use a .exit address then Tor will pass it on to the exit
>> 	relay. Now we reject the .exit stream outright, since that behavior
>> 	       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 	might be more expected by the user. Found and diagnosed by Scott
>> 	??????????????????????????????????
>> 	Bennett and Downie on or-talk.
>>
>> I understood the "Now we reject" part as meaning that the .exit  
>> support had
>> been completely removed.  I do not understand why that behavior  
>> "might be
>> more expected by the user."  In any case, the above note is why I've  
>> paused
>> at 0.2.2.7-alpha while waiting to discover some fairly easy-to-use  
>> alternative
>> method of testing exit behavior.
>
>Ah no, that's not what is meant here. The idea is that when .exit is  
>disabled,
>we reject connections to some domain ending in .exit, instead of passing
>that URL to the exit node. This is more expected behaviour because there
>is no .exit tld currently, so people telling to to go to xyz.exit are  
>most likely
>thinking that they are talking to a tor with the .exit functionality  
>enabled.
>
     Great!  Thanks for the clarification.  I'll go ahead and upgrade soon.
>>
>>> attacks where the exit node can choose who your exit is going to be,
>>> unless you use encrypted protocols when webbrowsing only.
>>>
>>     Regarding the attack route you mention, I have some firefox plug- 
>> ins
>> like NoRedirect and RefreshBlocker installed in addition to the  
>> recommended
>> plug-ins (including QuickJava, NoScript, and Torbutton especially)  
>> that should
>> help with automated stuff, and I'm in the habit of checking the  
>> actual URLs
>> in links before using the links manually.  In many cases, I don't  
>> even use
>> firefox to get stuff from the links, but rather do a copy-and-paste  
>> to a
>> wget(1) or some other downloader command in an xterm(1), so I have  
>> plenty of
>> opportunity to notice that sort of interference.  If those  
>> strategies still
>> miss something, please do let me know.
>
>I suppose you still load images and possibly other resources, too;
>those can be fetched from arbitrary locations unless disabled via
>special-purpose addons like RequestPolicy.

     Hmmm...yes, some images load without intervention, although many
do not.  Okay, I'll change my habits, so that torrc will have it turned
off by default, and I'll only turn it on (and send tor a SIGHUP) when
I really need it.  OTOH, thanks very much for the tip about RequestPolicy.
I didn't know about that one, so I'll check into it.
>
>>>>> # This file was generated by Tor; if youedit it, comments will not
>>>>> be pres=
>>>>
>>>>    I think the comment may be a lie.  It's most likely a torrc
>>>> produced by
>>>> vidalia, not tor.  (Someone please correct me if I've forgotten some
>>>> special
>>>> case in which tor does rewrite a torrc.)
>>>
>>> I think it is more likely that the file was written by Tor, via the
>>> SAFECONF
>>> torctl command.
>>>
>>     Okay, I guess I had forgotten tor implemented such a command,  
>> but who
>> is issuing the command?  Vidalia?
>>     Thanks for the information, Sebastian.
>
>Yes, Vidalia as the only Tor controller in a typical setup would be  
>issuing
>the saveconf command.
>
     Okay, so tor does the actual (re)write, but Vidalia is still the
perpetrator as far as the OP should be concerned. :-)  Thanks again.


                                  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/



More information about the tor-talk mailing list