[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: 25 tbreg relays in directory

Hash: SHA256

Jim McClanahan wrote:
> Scott Bennett wrote:
>>      On Mon, 29 Jun 2009 07:13:42 -0600 Jim McClanahan <jimmymac@xxxxxxxxxx>
>>> Scott Bennett wrote:
>>>>      On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan <jimmymac@xxxxxxxxxx>
>>>> wrote:
>>>>> Scott Bennett wrote:
>>>>>>      Ouch.  This provides another example in support of having a way
>>>>>> for the directory authorities to render insecure versions ...
>>>>>> and only usable as clients to connect to the tor project's web site to
>>>>>> download a current version of tor.
>>>>> This kind of thinking baffles me.  It seems diametrically opposed to the
>>>>> notion of free software.  I could understand if the outdated client was
>>>>      How so?  It's still free of charge, freely available, and freely
>>>> modifiable and redistributable.  (GPL3-licensed software doesn't
>>>> qualify, IMO.)
>>> I did not not mean it was not technically free software.  The license
>>> takes care of that.  My meaning is that the goal is to restrict people
>>> rather than to grant freedom.  It is an issue of perspective rather than
>>> license technicalities.  I probably could have phrased it better.
>>      Oh, okay.  Thanks for clarifying.
>>      The intent of my suggestions has been to restrict abuse harmful either
>> to an uninformed and unsuspecting user or to the tor network overall, not to
>> restrict "people".
> I have no problems with either of those goals.  Certainly, protecting
> the network is a priority.  Protecting "uninformed or unsuspecting"
> users gets trickier IMHO.  I'll admit this is a bit of a hot-button
> issue for me and I may have overreacted.  But I think care needs to be
> taken before cavalierly shutting something down to protect uninformed or
> unsuspecting users.  I agree with Ringo <2600denver@xxxxxxxxx> when he
> wrote (at Tue, 30 Jun 2009 00:06:01 -0400) "Remotely disabling Tor nodes
> is a slippery slope."
>> will do.
>>>>> endangering the Tor network (which was discussed in the portion of the
>>>>> comment I skipped over with the ellipsis).  And I would have no problem
>>>>      Insecure relays endanger the network
>>> That is why I inserted the ellipsis and made the parenthetical comment
>>> about it.  I am not arguing against neutralizing insecure relays.  The
>>> danger to the network is perfect justification IMO.
>>      Note that the version of tor that Pei Hanru reported here had been part
>> of the tbreg distribution is *not* secure.
> I was aware of that at the beginning of this discussion.
>>> It's not like the clients ended up there on their own w/o the consent of
>>> the user or owner.  Trying to enforce a policy on people when those
>>      Pei Hanru suggested otherwise.
> My point was the users knew that they were installing *some* software. 
> They may not have know that the software contained Tor or even what Tor
> is.  But I see the situation as similar to unscrupulous people slipping
> malware or other unknown software into packages people willingly
> install. While I don't approve of that, neither do I feel compelled to
> police it.  Which would be a futile endevour anyway.
>>      I would argue that those unsuspecting, involuntary tor operators were
>> indeed harmed and further that they were placed at significant risk of far
>> greater harms at the hands of that State.
> Yet the "harm at the hands of that State" has nothing to do (TMK) with
> the fact that the clients were insecure, but rather that they were Tor.
>>> technical argument.  Obviously, it is technically possible to do what
>>> you describe.  And because of the free license, it is technically
>>> possible and legally permissible for people to undo those changes on
>>> their copies of the software.  It is also possible for the software to
>>> lie to the network about what it is.  But as I stated, this attitude of
>>> trying to coerce other people baffles me.  I am not saying nobody does
>>> it.  The world is full of tyrants.
>>      Clearly, the above comments are inapplicable to this situation and
>> to what I was suggesting as a way to deal with similar situations in the
>> future.
> Again, maybe I was overreacting. But I do think people who are not
> trying to be tyrants nonetheless need to be very careful with "for your
> own good" attitudes.  IMO it gets very tricky.
>>> Just to flesh out my view a little more, I would have no problem with a
>>> configuration option that says "allow the tor network to nearly disable
>>> this client at <somebody's> discretion."  As long as it could be
>>      Oh, stop it.  That's ridiculous.  All the person would have to do
>> would be to upgrade to a valid version.  It does not restrict the user.
>> It just minimizes the damage that can be caused by software 
>> known/suspected to have something wrong with it.
> I probably should have canned the sarcasm, but I do think that any
> disabling of the client from the network should be easily reversible. 
> Part of that is just my philosophy.  But it also has a practical element
> in terms of what is required to resume functionality if the client
> suddenly and unexpectedly stop working.  Somebody may not wish to take
> the time to install at that moment.

I assume that Tor can (or could be made to) detect what OS it's being
run on.  Given that, what if Tor were to check it's current version
against the directory servers while it's creating circuits.

Then if the version running is judged too far out of date to be safe, it
could download the most recent version (via the Tor network of course)
for the OS it's running on and "auto-update" itself.

Yes, this might be considered a bit invasive but would result in the
node in question being up to date while causing only a momentary break
in connectivity.  There could also be an option in torrc to disable this
auto-update (which would be enabled by default) if desired.

That way if somebody decides to use Tor the way this collection of tbreg
nodes has, at least it can stay secure without user who don't know
anything about Tor and needed updates.

- --
The best way to get past my spam filter is to sign or encrypt
your email to me.
My PGP KeyId: 0x84D46604
Un-official Freenet 0.5 alternative download
Mixminion Message Sender, Windows GUI Frontend for Mixminion
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org