On Mon, 27 Apr 2009 17:32:16 -0400 Roger Dingledine <a...@mit.edu>
wrote:
>On Mon, Apr 27, 2009 at 05:27:38AM -0500, Scott Bennett wrote:
>> torstatus currently shows 25 different relays that are all named "tbreq"
^
I see I made a typo. It should have read "tbreg" like I wrote in the
header.
>> and appear to be in China. I wonder whether these are due to some benighted
>> user restarting tor after clearing its key files every time, or whether there
>> may be several that are all owned by one organization. All but four are
>> marked as being "offline".
>
>Interesting question.
>
>moria1 currently has 368 descriptors from relays with the nickname
>"tbreg", with 272 unique IP addresses. moria1 is voting about 67 distinct
>tbreg relays, and it believes 15 of them are Running.
Wow. :-(
>
>The other interesting feature is that they all say
>
>platform Tor 0.2.1.2-alpha (r15383) on Windows XP Service Pack 2 [workstation]
>{ terminal services, single user}
>
>But the identity keys are generally different.
>
>So it looks to me like somebody created a "ready-made" Tor relay image,
>and has a lot of people running it. The only reason we're noticing at
>all is because their relay image sets the nickname to tbreg.
It seems to me that it might have been better for them to have remained
"Unnamed".
>
>Now, is this because of a massive Chinese conspiracy to flood the Tor
>network with a block of centrally controlled Windows relays, or is it a
>whole lot of excited Tor users in China who really want to help out but
>don't realize that they're using an insecure and old version of Tor? You
>decide. :)
>
That brings up something that has bothered me for a long time. When
tor discovers that its version doesn't match any in either client-versions
or server-versions, it currently writes complaints about it to the log(s),
but seems to do nothing further about it. I'd like to see either of the
following.
a) Addition of three lines to the consensus documents to prevent use
of unsafe versions of tor
invalid-client-versions -- if tor detects that its version matches
one in this list, it will only allow streams to connect to the
tor project's web site. That will allow the user to connect with
at least a pretense of anonymity and concealment in order to obtain
an up-to-date version of tor. Matching a version in this list will
not affect tor's ability to operate as a relay.
invalid-server-versions -- if tor detects that its version matches
one on this list, it will refuse to run as a relay, but will not
prevent tor's operation as a client. tor clients will not choose
routes that include relays whose versions match versions in this
list for building circuits. This client behavior could be
implemented as additional code in circuitbuild.c, or it might be
more simply by having the authorities refuse to give a "Valid" flag
to such relays. Further, invalid-relay-versions should be an
accepted alias for invalid-server-versions in the interest of
eventually replacing the use of the term "server" with "relay" for
public (read: ISP) relations purposes.
invalid-exit-versions -- if tor detects that its version matches
one in this list, it will not allow exits if it is running as a
relay. tor clients will not build circuits to exits whose versions
match one in this list.
Wild-card specifications should be allowed in the lists of invalid
versions both in these consensus document lines and in the torrc
statements that would have to be part of the implementation of this
feature.
b) tor clients will not choose relays whose versions do not match a
version listed in server-versions when choosing routes for circuits.
This could be implemented as additional code in circuitbuild.c or
it might be implemented more simply by having the authorities refuse
to give a "Valid" flag to such relays.
The need for something like one of the above is especially strong, given
that both client users and relay operators may well never see log messages.
There are relays, some that have been up for a terribly long time, running
versions as old as 0.1.1.19-rc and 0.1.2.13.
My preference of the two alternatives above would be the former because
it allows not only more flexibility, but also enables a distinction between
versions that are merely old and versions that are known to be very unsafe
(e.g., the LINUX openssl key generation problem of some months ago, the bug
that allowed exits to get confused about which streams were to be fed data
coming back from exit connections) that should be avoided at all costs.
The latter alternative has the virtue of much easier and quicker
implementation, but at the cost of being far more restrictive than necessary.
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 *
**********************************************************************
