Re: 25 tbreg relays in directory
On Tue, 28 Apr 2009 09:59:05 -0400 and...@torproject.org wrote: >On Mon, Apr 27, 2009 at 11:57:17PM -0500, benn...@cs.niu.edu wrote 5.4K bytes >in 107 lines about: >: 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. > >Recently, we're started emailing the node operators (at least those with >valid contact info) suggesting they upgrade to at least 0.2.0.34-stable. >This method seems to have a better success ratio in getting nodes >upgraded from very old versions. At least, better than the log messages >that state your tor version is not recommended anymore. > I just took a closer look at the obsolete nodes. A number of them are medium- to very high-data-rate nodes, including some that peak at over 1 MB/sec. Obsolete nodes peaking at over 1 MB/sec currently include, according to torstatus, Node Name Peak Rate Version (KB/sec) Kryten 26880.1.2.19 TSL 5150 (!)0.1.2.19 c03d9ebf11720.1.2.19 3dd9T58cDbh84052b 11000.1.2.19 ohvi5poH5e 16950.2.0.31 Piratenschatzi 41800.2.0.32 ratatouille 11400.2.0.32 separator 13640.2.0.32 liquitor16370.2.0.32 Now, frankly, I am not particularly worried about relays running 0.2.0.32. The ones running any version in the 0.1.*.* series, however--and there are 118 of them showing in torstatus at present, including a 0.1.1.19-rc and a 0.1.2.9-rc that were restarted less than a day ago--should be ignored by clients. IIRC, there are known unsafe versions in the 0.2.0.x series that should be ignored by clients. Nevertheless, the high-data-rate nodes running 0.1.x.x versions are of great utility to the tor network, so I hope your efforts to contact operators of obsolete relays will focus on these first. Looking at 0.2.1.x relays, the situation is not nearly as bad, which is probably to have been expected because people following the development branch are more likely to try to stay reasonably current and are also more likely to pay attention to their tor log files. (As the exceptions that prove the rule, there are still some 0.2.0.x-alpha relays out there, though.) I see MopperSmurf 17880.2.1.10-alpha but there is also a low-data-rate Unnamed running 0.2.1.1-alpha. The core purpose of tor is to provide secure anonymity to the users of tor clients, but tor clients currently are not equipped to bypass obsolete/ unsafe tor relays as identified by tor's developers. This has bothered me for a long time, and I hope it will be rectified one way or another in the next stable and development versions. Of the two options I suggested previously, perhaps the next releases could use option b), which requires no changes to the statements used at the beginning of the descriptor and consensus files and no changes to torrc. The more nuanced option a) could be added when convenient to the -alpha versions, later to become part of the stable versions. 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 * **
Re: 25 tbreg relays in directory
On Tue, 28 Apr 2009 09:59:05 -0400 and...@torproject.org wrote: >On Mon, Apr 27, 2009 at 11:57:17PM -0500, benn...@cs.niu.edu wrote 5.4K bytes >in 107 lines about: >: 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. > >Recently, we're started emailing the node operators (at least those with >valid contact info) suggesting they upgrade to at least 0.2.0.34-stable. >This method seems to have a better success ratio in getting nodes >upgraded from very old versions. At least, better than the log messages >that state your tor version is not recommended anymore. > >We're also working on Tor Weather to enable automatic notifications, such >as "your server is out of date, please upgrade". > Those methods are all very nice, but do not address the clients' security problems. Warm and fuzzy feelings that tor node operators, who often do *not* put contact information into their torrc files, will oblige do nothing to enable clients to avoid nodes running versions that are known to be unsafe. Either of the options that I proposed here *would* address this issue, and the issue is one that calls for a solution. The first of the two options I suggested would also make it possible to distinguish between old relays that have security vulnerabilities for exit service but not for use as entry or middle nodes and old relays that are insecure for any use. If other options to deal with the problem are on people's minds, please speak up! 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 * **
Re: Version checking (was Re: 25 tbreg relays in directory)
On Tue, 2009-04-28 at 03:01 -0700, Tripple Moon wrote: > --- On Tue, 4/28/09, Scott Bennett wrote: > > > From: Scott Bennett > Subject: Re: 25 tbreg > relays in directory > To: or-talk@freehaven.net > Date: Tuesday, April > 28, 2009, 12:57 AM [cut for clarity] > 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 > [etc...cut for clarity] I also agree that there should be version > checking, i didn't even know it wasn't done so already... :( I would > furthermore suggest to build a version fingerprint that uses some > remotely calculated CRC value of the client. My reason for that is to > prevent the tor network to be poluted by specialy "tweaked/altered" > versions, which might endanger the security of the whole network. (Let > your imagination do a free run on possibilities in such cases). By > "remotely calculated CRC-value of the client" i mean that the > destination does the CRC calculation of the connecting client. Yes > this means the client needs to send all of its binary-self to the > destination. After this CRC-value has been calculated _once_ by a > destination, that destination should announce the presence of the > client to the whole network if its a valid client (not matter in what > mode it runs). These CRC-values could be centrally maintained by the > tor-development center and made accessible public or by a hidden > service. > > IMHO, this kind of "login procedure to enter the tor-network" will make it > more secure and manageable. > Again, i have _no_ idea at present how the tor program handles things at > present, so if its already done like that or even better just disregard what > i wrote :D > > So you propose sending the whole of the Tor binary over the network, having the authority do a CRC on it, and using that to check for validity? Just making sure I have the right impression. signature.asc Description: This is a digitally signed message part
Re: Be ready: We're switching version control systems
On Fri, Apr 24, 2009 at 08:29:55PM +0200, Juliusz Chroboczek wrote: [...] > This is excellent news. > > > - Better support for offline development. > > This also means that occasional contributors will be able to use the > RCS. > > A centralised RCS, such as CVS or SVN, segregates contributors into two > categories: those who have commit rights, and are able to enjoy all the > nice features of the RCS, and those who don't, for whom the RCS is > little more than a way to get the latest sources. > > With a decentralised RCS, all contributors are able to use the RCS; if > you're a non-comitter, you work on his private branch, which can be on > a different server or simply on your laptop. When your code is ready, > you either ask somebody with commit rights to pull your changes into the > official repository, or you push over e-mail. Exactly, though I'd like to make an appeal here. If you are working on a Tor-related project, the time to get in touch with us and the rest of the community is probably _not_ when you think your code is ready to be merged. Working in the dark like this can lead to duplicated effort (if you work on something someone else is also working on), and wasted effort (if your approach, on review, would have proved to have problems that you didn't see). Somebody should really expand the "HACKING" document to explain how to get started enhancing Tor, how to write a design proposal, what needs a design proposal, what versions are okay for new features vs bugfixes, how portable the code needs to be, why or-talk is not or-dev, and so on. yrs, -- Nick
Re: 25 tbreg relays in directory
Roger Dingledine wrote: 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. :) Can we signal them somehow? I.e.: have them change the config names? And/or update software versions? Udo
Re: Version checking (was Re: 25 tbreg relays in directory)
> By "remotely calculated CRC-value of the client" i mean that the destination does the CRC calculation of the connecting client. > Yes this means the client needs to send all of its binary-self to the > destination. That would be a pretty big upload for a dial-up user! I am also wondering what kind of danger you think a *client* can have for the Tor network. And if somebody wanted to circumvent, I would think the client could be modified so that when it claimed to be uploading itself, it was actually uploading a copy of an unmodified binary. Am I missing something? Also what would be gained from a CRC based on the *binary*? Wouldn't that change according to the system that compiled it?
Re: 25 tbreg relays in directory
On Mon, Apr 27, 2009 at 11:57:17PM -0500, benn...@cs.niu.edu wrote 5.4K bytes in 107 lines about: : 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. Recently, we're started emailing the node operators (at least those with valid contact info) suggesting they upgrade to at least 0.2.0.34-stable. This method seems to have a better success ratio in getting nodes upgraded from very old versions. At least, better than the log messages that state your tor version is not recommended anymore. We're also working on Tor Weather to enable automatic notifications, such as "your server is out of date, please upgrade". -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
My tor exit node is gone from the node list?
Hi there, For several months, we've been running a tor exit node (kyirong/A8BD 32A9 C2F2 0C4F 8ED2 C26C E477 0A24 85E3 CD22). Since a few days, it seems to have vanished from the list of nodes, and I cannot make it reappear. Neither notice.log nor debug.log (when enabled) show any suspicious entries or error messages: Apr 28 15:22:08.357 [notice] Tor 0.2.1.14-rc (r19307) opening log file. Apr 28 15:22:08.417 [notice] Parsing GEOIP file. Apr 28 15:22:09.105 [notice] Your Tor server's identity key fingerprint is 'kyirong A8BD 32A9 C2F2 0C4F 8ED2 C26C E477 0A24 85E3 CD22' Apr 28 15:22:15.553 [notice] We now have enough directory information to build circuits. Apr 28 15:22:15.553 [notice] Bootstrapped 80%: Connecting to the Tor network. Apr 28 15:22:15.643 [notice] Bootstrapped 85%: Finishing handshake with first hop. Apr 28 15:22:16.409 [notice] Bootstrapped 90%: Establishing a Tor circuit. Apr 28 15:22:17.817 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Apr 28 15:22:17.817 [notice] Bootstrapped 100%: Done. Apr 28 15:22:17.817 [notice] Now checking whether ORPort 89.248.169.108:8080 and DirPort 89.248.169.108:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Apr 28 15:22:19.106 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Apr 28 15:22:38.504 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Nothing else shows up after that, while debug.log is constantly being written to. Also, traffic logs suggest that the node is not used as much as it could be. Whats up with that? Thanks, Alexandru -- - www.posta.ro - Romanias first free webmail since 1998! _ - powered by www.posta.ro
Re: Version checking (was Re: 25 tbreg relays in directory)
On Tue, 28 Apr 2009 03:01:30 -0700 (PDT) Tripple Moon wrote: >--- On Tue, 4/28/09, Scott Bennett wrote: > >> From: Scott Bennett >> Subject: Re: 25 tbreg relays in directory >> To: or-talk@freehaven.net >> Date: Tuesday, April 28, 2009, 12:57 AM >[cut for clarity] >> 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 >[etc...cut for clarity] >I also agree that there should be version checking, i didn't even know it >wasn't done so already... :( >I would furthermore suggest to build a version fingerprint that uses some >remotely calculated CRC value of the client. >My reason for that is to prevent the tor network to be poluted by specialy >"tweaked/altered" versions, which might endanger the security of the whole >network. >(Let your imagination do a free run on possibilities in such cases). >By "remotely calculated CRC-value of the client" i mean that the destination >does the CRC calculation of the connecting client. >Yes this means the client needs to send all of its binary-self to the >destination. >After this CRC-value has been calculated _once_ by a destination, that >destination should announce the presence of the client to the whole network if >its a valid client (not matter in what mode it runs). >These CRC-values could be centrally maintained by the tor-development center >and made accessible public or by a hidden service. > Laying aside for the moment the matter of how the rest of the tor nodes should determine the trustworthiness/credibility of the tor instance making the announcement or even why the tor network, either as a "whole" or as individual nodes, should care about the integrity of a client (!), how to you propose to calculate a verification digest--a CRC would not likely be considered adequately reliable--based upon the executable binary of software that a) comes in many successive version, b) can be compiled for many hardware architectures, not all of which are necessarily known to the developers, c) can be compiled for many operating systems, not all of which are necessarily known to the developers, and d) can be compiled by untold numbers of versions of many compilers, not all of which are necessarily known to the developers? >IMHO, this kind of "login procedure to enter the tor-network" will make it >more secure and manageable. More secure and manageable for whom?? Big Brother? Obviously not for the supposedly anonymous tor user...jeesh. >Again, i have _no_ idea at present how the tor program handles things at >present, so if its already done like that or even better just disregard what i >wrote :D > It doesn't, and it shouldn't. 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 * **
Version checking (was Re: 25 tbreg relays in directory)
--- On Tue, 4/28/09, Scott Bennett wrote: > From: Scott Bennett > Subject: Re: 25 tbreg relays in directory > To: or-talk@freehaven.net > Date: Tuesday, April 28, 2009, 12:57 AM [cut for clarity] > 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 [etc...cut for clarity] I also agree that there should be version checking, i didn't even know it wasn't done so already... :( I would furthermore suggest to build a version fingerprint that uses some remotely calculated CRC value of the client. My reason for that is to prevent the tor network to be poluted by specialy "tweaked/altered" versions, which might endanger the security of the whole network. (Let your imagination do a free run on possibilities in such cases). By "remotely calculated CRC-value of the client" i mean that the destination does the CRC calculation of the connecting client. Yes this means the client needs to send all of its binary-self to the destination. After this CRC-value has been calculated _once_ by a destination, that destination should announce the presence of the client to the whole network if its a valid client (not matter in what mode it runs). These CRC-values could be centrally maintained by the tor-development center and made accessible public or by a hidden service. IMHO, this kind of "login procedure to enter the tor-network" will make it more secure and manageable. Again, i have _no_ idea at present how the tor program handles things at present, so if its already done like that or even better just disregard what i wrote :D
