Out-of-date Tors (was Re: 25 tbreg relays in directory)

[Roger Dingledine <arma@xxxxxxx>]

On Mon, Apr 27, 2009 at 11:57:17PM -0500, Scott Bennett wrote:
>      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.

Right. Actually, we've recently taught Vidalia how to pop up a box
telling you you're out of date. For those using Thandy, the eventual
goal is for Vidalia and Thandy to automatically fetch the new versions
and check their sigs, which should make it a lot easier to upgrade.

But you're right, this is a real problem. Some of our users use Linux
packaging systems that keep them mostly up to date. But some are on Ubuntu
(...insert expletives here). And some are on BSD, which either provides
no easy upgrades, or the users don't use them.

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

That's a better idea than our long-ago strategy of "if Tor sees that its
version is not listed as recommended, it emits a warning log entry and
then exits". That old idea had two problems: a) some people ran their
Tors in a while(1) loop to restart after crashes, which caused them to
pull down a new consensus, exit, repeat, which beat up the directories. b)
people fretted that we had implemented a "remote kill switch" for clients.

So your idea above would solve (a), but it would still leave (b), which
was ultimately the reason why we took that "feature" out in 0.1.1.6-alpha:
http://archives.seul.org/or/cvs/Aug-2005/msg00098.html

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

Two thoughts here.

First, this decision is probably better made at the directory
authorities. They can decide which relays to list in their votes. Check
out dirserv_get_status_impl() in dirserv.c:

  /* 0.1.1.17-rc was the first version that claimed to be stable, * doesn't
   * crash and drop circuits all the time, and is even vaguely
   * compatible with
   * the current network */
  if (platform && !tor_version_as_new_as(platform,"0.1.1.17-rc")) {
    if (msg)
      *msg = "Tor version is far too old to work.";
    return FP_REJECT;
  }

So we could easily bump up that "minimum version" number.

The second thought: these Tor versions aren't *so* bad, compared to the
wide variety of other applications out there. Why are we singling out
Tor versions? Should we check if you're running a new enough patch-level
of Windows, and lock you out otherwise? Should we port-scan the relays
and look for sketchy daemons?

On the one hand, "yes, do everything reasonable to make sure clients
will avoid dangerous relays." But on the other hand, Tor gains security
from diversity and dispersal of relays, and an active attack is more work
(and more risk) than various large-scale passive threats. So I'm
hesitant to cut out too many relays.

And at the same time, when the Tor network is way overloaded and all
the users are crying for more performance, should we really be removing
relays from the list? :)

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

Again, this is better done by setting FP_BADEXIT at the directory
authorities.

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

Actually, you don't want to do this with Valid. Well, you might not. Tor
clients will still use non-Valid relays for middle hops and rendezvous
hops. Check out AllowInvalidNodes in the man page.

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

Actually, the authorities have an enormous list of bad keys, so they can
recognize most relays that show up using a weak key. That's important,
since you could conceivably run a modern Tor with a weak key, so it's
not a matter of Tor version.

But yes, there is definitely a tradeoff here. I'm not sure where the
right point in the tradeoff is. But my intuition is that cutting 0.1.2.x
relays out of the network would hurt more than help at this point. But
for the few remaining 0.1.1.x relays? Hm.

--Roger