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
