Re: 25 tbreg relays in directory
Arjan wrote: > Niels Elgaard Larsen wrote: > [...] >> I run an TOR-access-point. Users have no way of upgrading TOR on it. They >> probably do not >> even know that they are using TOR. If I fail to upgrade the access-point at >> we lock it >> out, the users loose the internet connection. And the users are not that >> anonymous anyway. >> The wireless traffic is not through TOR. > > I don't think that redirecting traffic of unsuspecting users through Tor > is wise. Using TOR will make things less secure / anonymous for the > people using your wireless AP. Not if their alternative is to use the same open wireless AP without TOR. The main reason is to protect the AP owner, not just the AP users. The AP owner can wish not to run a non-TOR open AP for the same reasons as not to run a TOR exit-node, e.g., because many users would suffer if the internet connection was terminated even temporarily. > People using an open, unencrypted, AP can have their traffic sniffed by: > - other people nearby > - AP owner > - ISP of the AP owner > - government > - ... (depends on the destination) > When sending the traffic over TOR, it can also be monitored by: > - exit node operators (some owned by crackers / government agencies) > - ISPs of exit node operators > - governments of exit node operators Yes, but no longer by the ISP of the AP owner or government (unless they bug the AP). > Since the AP user doesn't know he's using TOR, he will probably transmit > information that shows his identity. If someone uses an open access-points run by someone he does not know and put personal info and identity in cleartext, the info will not be personal for long anyway and using a TOR AP is probably better than e.g., an AP in cafe or school. > He may end up on a government watch > list, because they know that all TOR users are potential child > pornographers / terrorists. I have absolutely no problem sending my name in cleartext through TOR, when I do not need to be anonymous. Of course I could already be on Danish Government watch list :-)
Re: 25 tbreg relays in directory
Arjan wrote: > > Jim McClanahan wrote: > [...] > > 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 <2600den...@gmail.com> when he > > wrote (at Tue, 30 Jun 2009 00:06:01 -0400) "Remotely disabling Tor nodes > > is a slippery slope." > > In my humble opinion, protecting uninformed or unsuspecting users / > relay operators should be a priority. The discussion was about Tor *clients* not Tor *servers*. I have repeatedly stated I didn't have problems with disabling the servers if that was needed to protect the network. And while I didn't specifically mention "client" in what was quoted above, I did reiterate that protecting the network was important.
Re: 25 tbreg relays in directory
Martin Fick wrote: > --- On Thu, 7/2/09, Arjan wrote: >> He may end up on a government watch list, because they know that all >> TOR users are potential child pornographers / terrorists. > > > Give me a break, so are all internet users, so are all people > of the world. This kind of silly slurring of tor users is > really unnecessary, isn't it? I omitted the ;-) in that example, because I thought it was obvious. I'll rephrase what I meant to say: People who choose to use Tor will think about the consequences. They will encrypt their traffic, hide their identity or simply refrain from transmitting things via Tor that can get them into trouble somewhere on this planet. People who are using Tor without them knowing it, may not be so careful.
Re: 25 tbreg relays in directory
--- On Thu, 7/2/09, Arjan wrote: > He may end up on a government watch list, because they know that all > TOR users are potential child pornographers / terrorists. Give me a break, so are all internet users, so are all people of the world. This kind of silly slurring of tor users is really unnecessary, isn't it? -Martin
Re: 25 tbreg relays in directory
Niels Elgaard Larsen wrote: [...] > I run an TOR-access-point. Users have no way of upgrading TOR on it. They > probably do not > even know that they are using TOR. If I fail to upgrade the access-point at > we lock it > out, the users loose the internet connection. And the users are not that > anonymous anyway. > The wireless traffic is not through TOR. I don't think that redirecting traffic of unsuspecting users through Tor is wise. Using TOR will make things less secure / anonymous for the people using your wireless AP. People using an open, unencrypted, AP can have their traffic sniffed by: - other people nearby - AP owner - ISP of the AP owner - government - ... (depends on the destination) When sending the traffic over TOR, it can also be monitored by: - exit node operators (some owned by crackers / government agencies) - ISPs of exit node operators - governments of exit node operators Since the AP user doesn't know he's using TOR, he will probably transmit information that shows his identity. He may end up on a government watch list, because they know that all TOR users are potential child pornographers / terrorists.
Re: 25 tbreg relays in directory
Jim McClanahan wrote: [...] > 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 <2600den...@gmail.com> when he > wrote (at Tue, 30 Jun 2009 00:06:01 -0400) "Remotely disabling Tor nodes > is a slippery slope." In my humble opinion, protecting uninformed or unsuspecting users / relay operators should be a priority. Numbers of relays running a particular Tor version (extracted from the current consensus): 1 0.1.1.19-rc 2 0.1.1.23 2 0.1.1.25 2 0.1.1.26 1 0.1.2.13 2 0.1.2.14 7 0.1.2.16 20 0.1.2.17 11 0.1.2.18 73 0.1.2.19 1 0.1.2.3-alpha 1 0.1.2.9-rc 3 0.2.0.30 (r15956) 32 0.2.0.31 (r16744) 23 0.2.0.32 (r17346) 39 0.2.0.33 (r18212) 1048 0.2.0.34 (r18423) 411 0.2.0.35 1 0.2.0.4-alpha 2 0.2.0.7-alpha (r11572) 1 0.2.1.10-alpha (r17969) 9 0.2.1.11-alpha (r18192) 10 0.2.1.12-alpha (r18423) 1 0.2.1.13-alpha-dev (r19091) 2 0.2.1.13-alpha-dev (r19200) 1 0.2.1.13-alpha-dev (r19220) 11 0.2.1.13-alpha (r18828) 29 0.2.1.14-rc (r19307) 1 0.2.1.14-rc (r19364) 1 0.2.1.14-rc (r19715) 1 0.2.1.14-rc (r19870) 40 0.2.1.15-rc 100 0.2.1.16-rc 8 0.2.1.2-alpha (r15383) 2 0.2.1.7-alpha (r17216) 17 0.2.2.0-alpha-dev Just remove all relays from the directory that are running old versions and only keep 0.2.0.34, 0.2.0.35, 0.2.1.15-rc, 0.2.1.16-rc and maybe 0.2.2.0 listed. You'll only lose about 300 relays, so no big loss. A relay operator should be able to keep his Tor updated. If he doesn't, chances are that his machine will be compromised. That's bad for him. It's also bad for the Tor users (and their anonymity), because some entity might be able to compromise a large number of Tor relays. Relays that are running without the PC owner knowing about it should also be removed. The PC owner might get into trouble with his ISP or government and the relay also has a higher risk of being compromised.
Re: 25 tbreg relays in directory
I resend this since it was deleted by greylisting. Original Message Subject: Re: 25 tbreg relays in directory Date: Wed, 01 Jul 2009 17:19:34 +0200 From: Niels Elgaard Larsen To: or-talk@freehaven.net References: <200906290445.n5t4jolj007...@mp.cs.niu.edu> <4a48a211.1c087...@copper.net> Jim McClanahan 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 > 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 > with a friendly advisory as long is it wasn't incessant nagware that > couldn't be disabled. I agree. And I object to assuming that someone running an old version is necessarily uninformed. There can be circumstances where a user have to choose between and old TOR client or no anonymity at all, or even no internet. E.g. We do try to make up-to-date versions of the Polippix CD. But someone may be stuck in a hotel room somewhere, wanting to be anonymous and remembering putting a Polippix CD in the suitcase years ago, or an USB-stick with TBB. Yes, it is possible to upgrade TOR through TOR given a lot of time and RAM, but then again we do not know if there is enough time and RAM. I run an TOR-access-point. Users have no way of upgrading TOR on it. They probably do not even know that they are using TOR. If I fail to upgrade the access-point at we lock it out, the users loose the internet connection. And the users are not that anonymous anyway. The wireless traffic is not through TOR. > But I don't understand the desire to dictate to > people or some nanny viewpoint of trying to save people from > themselves. (Before somebody makes an argument of keeping the Internet > free of compromised machines, I rather imagine the number of machines > compromised because of Tor software would be lost in the statistical > noise of all the other ways machines get compromised. And I don't think > the unsavory purpose these "tbreg" instances are put to is a relevant > factor.) Why should a client even provide its version? (of the code, not versions of protocols it understand). If someone ship 10 CD's/USB-keys to eg Iran they will all have the same version, which in a year could be almost unique. You can already trach IP-numbers to e.g. Iran, but why make it easy to detect when e.g. a new shipment arrives or how people move around. -- Niels
Re: 25 tbreg relays in directory
On Wed, 01 Jul 2009 19:46:49 -0400 Marcus Griep wrote: >On Wed, 2009-07-01 at 17:15 -0600, Jim McClanahan wrote: >> I remain unconvinced that what happened in the case of "tbreg" should be >> determining policy for the Tor project, at least as far as client >> activity is concerned. To the extent the people who installed really >> didn't know it involved Tor, it seems to me that, if not technically >> malware, it is at least a close cousin (where software creators are not >> being up front with users). Trying to, in effect, be the guardian of >> such users is (IMHO) a losing proposition. The tbreg case combines two problems. That combination appears to me to be the source of some confusion and writing at cross-purposes in the discussion. One problem is that someone was distributing a package that installed a bad version of tor. This risked considerable harm not only to the users onto whose machines it installed the bad version, but also to tor users everywhere. Such risks point up the need to have software that can recognize when it has been identified as being defective and then refuse to serve in any capacity beyond assisting in obtaining an up-to-date version to replace it. The second problem is that the tbreg installer may have been installing software onto people's machines by stealth and/or misrepresentation and then activating it. This situation is not necessarily specific to tor and doesn't in itself reduce anonymity gained through the use of tor. I think it will be helpful to the discussion if proposals of remedies, as well as proposals *not* to remedy a problem, clearly identify which of the two problems they address. > >Perhaps the better action, in the event that there is clear evidence >that a group is using the Tor network to abuse a service provider, such >as eBay, would be to alert them to what is happening, and help to >provide them the tools they need to stem the tide, even if that means >that they temporarily block the Tor network or are able to gain some >insight into how the fraudulent activity is occurring. After all, >providing this means is in part what the Tor DNS Exit List and Bulk Exit >Lists are for. > >As well, by being forthright the Tor network could be seen as a >generally good network, but which has bad users too, rather than being >found as a major source of fraud after the fact and determined a bad >network overall. > >Possibly out on my own limb, but that's my opinion. > No, I think those are points well worth considering. Some of them have been discussed here in the past, but may now be due for revisiting. 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 Wed, 2009-07-01 at 17:15 -0600, Jim McClanahan wrote: > I remain unconvinced that what happened in the case of "tbreg" should be > determining policy for the Tor project, at least as far as client > activity is concerned. To the extent the people who installed really > didn't know it involved Tor, it seems to me that, if not technically > malware, it is at least a close cousin (where software creators are not > being up front with users). Trying to, in effect, be the guardian of > such users is (IMHO) a losing proposition. Perhaps the better action, in the event that there is clear evidence that a group is using the Tor network to abuse a service provider, such as eBay, would be to alert them to what is happening, and help to provide them the tools they need to stem the tide, even if that means that they temporarily block the Tor network or are able to gain some insight into how the fraudulent activity is occurring. After all, providing this means is in part what the Tor DNS Exit List and Bulk Exit Lists are for. As well, by being forthright the Tor network could be seen as a generally good network, but which has bad users too, rather than being found as a major source of fraud after the fact and determined a bad network overall. Possibly out on my own limb, but that's my opinion. -- Marcus Griep GPG Key ID: 0x070E3F2D —— https://torproj.xpdm.us Ακακια את.ψο´, 3° signature.asc Description: This is a digitally signed message part
Re: 25 tbreg relays in directory
Edward Langenback wrote: > Jim McClanahan wrote: > > 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. I guess that would depend on the OS and how it is configured. If Tor is running without privilege, as recommended, I would think in most scenarios it would not have the ability to update itself. If something is configured "non-standard" (whatever that may mean in a particular situation) then I would guess the attempt to update would not have the desired result even if Tor had privilege. That said, it is my understanding that on MS Windows, Firefox has such an auto-update mechanism although I am not familiar with the details. Personally, I like to be in charge of what happens on my computers. I remain unconvinced that what happened in the case of "tbreg" should be determining policy for the Tor project, at least as far as client activity is concerned. To the extent the people who installed really didn't know it involved Tor, it seems to me that, if not technically malware, it is at least a close cousin (where software creators are not being up front with users). Trying to, in effect, be the guardian of such users is (IMHO) a losing proposition.
Re: 25 tbreg relays in directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim McClanahan wrote: > Scott Bennett wrote: >> On Mon, 29 Jun 2009 07:13:42 -0600 Jim McClanahan >>> Scott Bennett wrote: On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan 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 <2600den...@gmail.com> 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 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 ph
Re: 25 tbreg relays in directory
Scott Bennett wrote: > > On Mon, 29 Jun 2009 07:13:42 -0600 Jim McClanahan > >Scott Bennett wrote: > >> > >> On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan > >> > >> 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 <2600den...@gmail.com> 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 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 s
Re: 25 tbreg relays in directory
Hello!
[Please reply to list only. Thanks.]
Scott Bennett wrote to or-t...@seul.org, punkle.jo...@gmail.com on Tue, 30 Jun
2009 02:15:32 -0500 (CDT):
> I haven't lately looked at the distribution of relays over version strings,
Just quick stat from
perl -e '
while (<>) {
$tor{$1}++ if /^platform (.*?) on /;
}
for (sort keys %tor) {
printf "%8d %s\n", $tor{$_}, $_;
}
' cached-descriptors
and some manual reordering:
1 Tor 0.1.1.19-rc
4 Tor 0.1.1.23
2 Tor 0.1.1.25
3 Tor 0.1.1.26
1 Tor 0.1.2.9-rc
1 Tor 0.1.2.13
5 Tor 0.1.2.14
1 Tor 0.1.2.15
5 Tor 0.1.2.16
26 Tor 0.1.2.17
18 Tor 0.1.2.18
87 Tor 0.1.2.19
1 Tor 0.2.0.2-alpha (r10455)
1 Tor 0.2.0.4-alpha
2 Tor 0.2.0.6-alpha (r11277)
1 Tor 0.2.0.7-alpha (r11572)
1 Tor 0.2.0.28-rc (r15188)
6 Tor 0.2.0.30 (r15956)
30 Tor 0.2.0.31 (r16744)
28 Tor 0.2.0.32 (r17346)
60 Tor 0.2.0.33 (r18212)
1410 Tor 0.2.0.34 (r18423)
411 Tor 0.2.0.35
1 Tor 0.2.1.1-alpha (r15195)
19 Tor 0.2.1.2-alpha (r15383)
2 Tor 0.2.1.7-alpha (r17216)
1 Tor 0.2.1.8-alpha (r17523)
1 Tor 0.2.1.9-alpha (r1)
2 Tor 0.2.1.10-alpha (r17969)
8 Tor 0.2.1.11-alpha (r18192)
15 Tor 0.2.1.12-alpha (r18423)
14 Tor 0.2.1.13-alpha (r18828)
2 Tor 0.2.1.13-alpha-dev
1 Tor 0.2.1.13-alpha-dev (r19091)
2 Tor 0.2.1.13-alpha-dev (r19200)
1 Tor 0.2.1.13-alpha-dev (r19220)
1 Tor 0.2.1.14-rc
43 Tor 0.2.1.14-rc (r19307)
1 Tor 0.2.1.14-rc (r19364)
1 Tor 0.2.1.14-rc (r19712)
1 Tor 0.2.1.14-rc (r19715)
56 Tor 0.2.1.15-rc
118 Tor 0.2.1.16-rc
18 Tor 0.2.2.0-alpha-dev
Alexander Cherepanov
Re: 25 tbreg relays in directory
On Tue, 30 Jun 2009 01:13:13 -0500 punkle jones wrote: >On Mon, Jun 29, 2009 at 2:59 PM, Scott Bennett wrote: > >> On Mon, 29 Jun 2009 09:19:21 -0500 punkle jones < >> punkle.jo...@gmail.com> >> wrote: >> >Unlurking for the first time, I think. >> >> Welcome to the fray! ;) >> > >> >Why not join forces with a popular freeware/shareware product like Aim or >> >Winamp, with an "uncheck to opt out" option and a description of tor. >> Such >> >a bundle could be preset to relay, and there's got to be a magic bandwidth >> >that most western users could tolerate. Is it ethically wrong to insert >> TOR >> >into the userspace of the less-informed by associating it with a popular >> >(hopefully not unsavory) download? Does this concept fly in the face of >> >free will? Is it just too sneaky? It's not like you'd be putting five >> new >> >toolbars into their browser. >> > >> Take a look at some reasons, beginning at >> >> https://www.torproject.org/download.html.en#Warning >> >> Then let us know whether you still see a way for such an "uncheck to opt >> out" >> arrangement to be a good idea. Keep in mind that, in general, people do >> not >> currently read EULAs displayed by software installer packages, so you're >> not >> likely to get them to read and understand a bunch of pages from the tor >> project's web site in the middle of installing a different package that >> also >> includes tor. >> >> Well, my thinking was along the lines of causing more TOR installations, >with the motivation provided up front and not during an installation.. Just Well, we have recently and suddenly gotten about 40% more relays, very few of which seem to be tbreg relays, so it certainly looks like someone or something has achieved that result. >because it's installed doesn't mean it has to be used. I imagined a >good-faith service that someone runs because they feel it benefits everyone >without necessarily needing it themselves. The sketchy part is getting >folks to run another thing on their computer to help other folks out. >Unless a ton of new tor installations would be a burden instead of a boon. > If they are legitimate, it would be very much a boon. I haven't lately looked at the distribution of relays over version strings, so I don't have a good benchmark to use for comparison if I decided to look at the current distribution. Does anyone else happen to have any records that could be used for this purpose? If, OTOH, they are new relays using insecure, out-of-date versions like the 0.2.1.2-alpha that was reported as being the version used by the tbreg relays, then "burden" would still not be a good description of the situation. 8-| 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 Mon, 29 Jun 2009 07:13:42 -0600 Jim McClanahan wrote: >Scott, when I did a "reply" on your email, it (tried to) sent it your >personal email account rather than the list. You probably were replying to the message sent directly to you, so that is quite likely. :-) > >-- > >Scott Bennett wrote: >> >> On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan >> 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 happen to like, to the extent I understand it, GPLv3. But I don't >see how it is relevant to this discussion and I don't know why it was >injected into it.) > That was just a side comment. The viral license is, as I understand it, the primary motivating reason for the recent decision by the FreeBSD project to write its own gcc-compatible C compiler in order to keep GPL3 contamination from getting the upper hand over FreeBSD. Replacement of other GNU tools in FreeBSD has been underway for some time already. The BSD license does not suffer from the pernicious interference of GPL3, and the FreeBSD project would like to keep it *Free*BSD. There is a history to this way of thinking. Remember that all of the modern *BSDs are descended from 4.4BSD-lite, which was released in response to all the difficulties caused by the AT&T UNIX license that had culminated in a lawsuit against the University of California Board of Regents (or Trustees--I don't now recall what they were called at the time). The AT&T license problems are also the reason Linus Torvalds decided so long ago that he'd dump UNIX and write his own. Likewise for MINIX. I don't know what Torvalds will do this time around w.r.t. GPL3, nor what the other *BSD projects 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. > >> Insecure clients installed >> virally onto systems without notice to the users endanger those users. > >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. >people are not harming others reeks (IMO) of unsavory things like police >states and nanny states. I am opposed. It is personal perspective, not 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. >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. No one suggested that anyone be prevented from deliberately installing and, at their option, configuring tor to suit their taste. What was suggested was a way to disable bad software to prevent it from harming the unsuspecting. tor is still open source software. If you have a bad version, but really do want to run a bad version, you are free to change it to make it think it is valid even when it isn't. Of course, if a large enough fraction of tor users w
Re: 25 tbreg relays in directory
On Mon, Jun 29, 2009 at 2:59 PM, Scott Bennett wrote: > On Mon, 29 Jun 2009 09:19:21 -0500 punkle jones < > punkle.jo...@gmail.com> > wrote: > >Unlurking for the first time, I think. > > Welcome to the fray! ;) > > > >Why not join forces with a popular freeware/shareware product like Aim or > >Winamp, with an "uncheck to opt out" option and a description of tor. > Such > >a bundle could be preset to relay, and there's got to be a magic bandwidth > >that most western users could tolerate. Is it ethically wrong to insert > TOR > >into the userspace of the less-informed by associating it with a popular > >(hopefully not unsavory) download? Does this concept fly in the face of > >free will? Is it just too sneaky? It's not like you'd be putting five > new > >toolbars into their browser. > > > Take a look at some reasons, beginning at > > https://www.torproject.org/download.html.en#Warning > > Then let us know whether you still see a way for such an "uncheck to opt > out" > arrangement to be a good idea. Keep in mind that, in general, people do > not > currently read EULAs displayed by software installer packages, so you're > not > likely to get them to read and understand a bunch of pages from the tor > project's web site in the middle of installing a different package that > also > includes tor. > > Well, my thinking was along the lines of causing more TOR installations, with the motivation provided up front and not during an installation.. Just because it's installed doesn't mean it has to be used. I imagined a good-faith service that someone runs because they feel it benefits everyone without necessarily needing it themselves. The sketchy part is getting folks to run another thing on their computer to help other folks out. Unless a ton of new tor installations would be a burden instead of a boon. > > > 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 * > ** > -- Punkle Jones // cDc/NSF NON-31337 humanoid
Re: 25 tbreg relays in directory
Remotely disabling Tor nodes is a slippery slope. So it sounds like somebody is abusing the Tor network to do auction fraud, but that kind of stuff occasionally happens with a system like Tor. Should we filter exit nodes because we know this is going on? I wouldn't think anybody would answer yes to that. We already can disable nodes by marking them 'invalid'. I for one would never run Tor if I knew that directory servers could run code on my machine or tell my Tor client to shut down. As for disabling these nodes because they're zombied, I again don't think this is Tor's place. If somebody wants to contact the ISP or the owner of the zombie machines that's one thing but I think as long as there's a computer routing traffic for us that isn't malicious, we should keep it. I don't think there should be a 'tor police' that goes around determining if a node is legitimately obtained or not. Ringo Alec Burgess wrote: > > punkle jones (punkle.jo...@gmail.com) wrote (in part) (on 2009-06-29 > at 10:19): >> Unlurking for the first time, I think. >> >> Why not join forces with a popular freeware/shareware product like >> Aim or Winamp, with an "uncheck to opt out" option and a description >> of tor. Such a bundle could be preset to relay, and there's got to >> be a magic bandwidth that most western users could tolerate. Is it >> ethically wrong to insert TOR into the userspace of the less-informed >> by associating it with a popular (hopefully not unsavory) download? >> Does this concept fly in the face of free will? Is it just too >> sneaky? It's not like you'd be putting five new toolbars into their >> browser. > > I've been following this thread with interest. From what I've read our > best guess as to why other users are installing the package which uses > Tor is to provide the means to circumvent the restrictions on quickly > creating multiple accounts for a particular auction group (*Taobao)*. > Correct so far? Presumably the effect of doing this are likely to be > unwelcome to *Taobao.com * management and/or other non-participating > users/bidders/sellers? > > Question: ignoring any possible bad reputation this brings to the TOR > community at large does this have the side-effect of increasing exit > nodes and thereby providing more capacity to everyone? Or is typical > usage for those who want to create the multiple accounts just to open > them briefly and then cease immediately with no net noticeable effect on > the TOR network as a whole? >
Re: 25 tbreg relays in directory
punkle jones (punkle.jo...@gmail.com) wrote (in part) (on 2009-06-29 at 10:19): Unlurking for the first time, I think. Why not join forces with a popular freeware/shareware product like Aim or Winamp, with an "uncheck to opt out" option and a description of tor. Such a bundle could be preset to relay, and there's got to be a magic bandwidth that most western users could tolerate. Is it ethically wrong to insert TOR into the userspace of the less-informed by associating it with a popular (hopefully not unsavory) download? Does this concept fly in the face of free will? Is it just too sneaky? It's not like you'd be putting five new toolbars into their browser. I've been following this thread with interest. From what I've read our best guess as to why other users are installing the package which uses Tor is to provide the means to circumvent the restrictions on quickly creating multiple accounts for a particular auction group (*Taobao)*. Correct so far? Presumably the effect of doing this are likely to be unwelcome to *Taobao.com * management and/or other non-participating users/bidders/sellers? Question: ignoring any possible bad reputation this brings to the TOR community at large does this have the side-effect of increasing exit nodes and thereby providing more capacity to everyone? Or is typical usage for those who want to create the multiple accounts just to open them briefly and then cease immediately with no net noticeable effect on the TOR network as a whole? -- Regards ... Alec (bura...@gmail & WinLiveMess - alec.m.burg...@skype)
Re: 25 tbreg relays in directory
On Mon, 29 Jun 2009 09:19:21 -0500 punkle jones wrote: >Unlurking for the first time, I think. Welcome to the fray! ;) > >Why not join forces with a popular freeware/shareware product like Aim or >Winamp, with an "uncheck to opt out" option and a description of tor. Such >a bundle could be preset to relay, and there's got to be a magic bandwidth >that most western users could tolerate. Is it ethically wrong to insert TOR >into the userspace of the less-informed by associating it with a popular >(hopefully not unsavory) download? Does this concept fly in the face of >free will? Is it just too sneaky? It's not like you'd be putting five new >toolbars into their browser. > Take a look at some reasons, beginning at https://www.torproject.org/download.html.en#Warning Then let us know whether you still see a way for such an "uncheck to opt out" arrangement to be a good idea. Keep in mind that, in general, people do not currently read EULAs displayed by software installer packages, so you're not likely to get them to read and understand a bunch of pages from the tor project's web site in the middle of installing a different package that also includes tor. 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 Mon, 29 Jun 2009 07:47:23 -0500 Edward Langenback wrote: >Scott Bennett wrote: >> On Sun, 28 Jun 2009 20:09:25 +0800 Pei Hanru >> wrote: >>> On 2009-04-27 18:27 CST, Scott Bennett wrote: torstatus currently shows 25 different relays that are all named "tbreq" and appear to be in China. I wonder whether these are due to some benighted > >snip > >>> I've downloaded the software and tested, the version of Tor in it is >>> indeed 0.2.1.2-alpha, torrc in it is >> >> Ouch. This provides another example in support of having a way for >> the directory authorities to render insecure versions inoperable/unusable >> as relays to the rest of the network and only usable as clients to connect >> to the tor project's web site to download a current version of tor. > >How about simply take a page from Freenet? Each new build of Freenet >comes with a "lastGoodVersion=" variable that contains the version >number of the oldest build it's willing to talk to. 1) Sometimes a security bug is introduced into a particular version, rather than having been present in tor since the beginning. When found, the problem can be fixed in a new release. That means that the security bug renders a range of one or more releases dangerous to use, while versions both older and newer may be okay to use. Setting only the new start of a range could, depending upon timing, render the majority of relays in the tor network unusable for no good reason. 2) Calling the *first* good version the "lastGoodVersion" strikes me as a poor idea because of the potential for causing confusion. 3) The current setup regarding versions enables the directory authorities to establish the currently recommended versions for use as clients and a similar set of relay versions. (At present, an instance of tor that doesn't find its own version in the relevant list issues a warning message to a log file that many tor users rarely, if ever, see and thus do not respond to.) Why would having a statically compiled list that is certain to become obsolete be a better idea? > >Nodes older than that can't connect to the network for anything except >updating the out of date node. > That is part of what I have been recommending. 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
Unlurking for the first time, I think. Why not join forces with a popular freeware/shareware product like Aim or Winamp, with an "uncheck to opt out" option and a description of tor. Such a bundle could be preset to relay, and there's got to be a magic bandwidth that most western users could tolerate. Is it ethically wrong to insert TOR into the userspace of the less-informed by associating it with a popular (hopefully not unsavory) download? Does this concept fly in the face of free will? Is it just too sneaky? It's not like you'd be putting five new toolbars into their browser. On Mon, Jun 29, 2009 at 8:13 AM, Jim McClanahan wrote: > Scott, when I did a "reply" on your email, it (tried to) sent it your > personal email account rather than the list. > > -- > > Scott Bennett wrote: > > > > On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan < > jimmy...@copper.net> > > 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. > > (I happen to like, to the extent I understand it, GPLv3. But I don't > see how it is relevant to this discussion and I don't know why it was > injected into it.) > > > > > >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. > > > Insecure clients installed > > virally onto systems without notice to the users endanger those users. > > 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 > people are not harming others reeks (IMO) of unsavory things like police > states and nanny states. I am opposed. It is personal perspective, not > 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. > > 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 discretion." As long as it could be > disabled. But I really wonder why Tor developers would be interested in > spending the time to implement such a thing. > > > > > >with a friendly advisory as long is it wasn't incessant nagware that > > >couldn't be disabled. But I don't understand the desire to dictate to > > > > I don't think the current log messages are so influential as all > that. > > Just take a look at the current consensus. :-( > > > > >people or some nanny viewpoint of trying to save people from > > >themselves. (Before somebody makes an argument of keeping the Internet > > >free of compromised machines, I rather imagine the number of machines > > >compromised because of Tor software would be lost in the statistical > > > > Again, when the software is installed by stealth onto the machines > > of unsuspecting users, then the probability on each user's machine > becomes > > 100%. In other words, the number of machines w.r.t. the user is 1 out of > 1, > > a ratio that cannot be considered "lost in the noise" for that user. > > By stealth??? If that is really so, I guess you could try to make the > same argument about *any* free software that somebody decided to turn > into malware. But I am still unconvinced the people who installed > didn't know they were installing something. > > > >noise of all the other ways machines get compromised. And I don't think > > >the unsavory purpose these "tbreg" instances are put to is a relevant > > >factor.) > > > > > How so? I note that you deleted all the relevan
Re: 25 tbreg relays in directory
Scott, when I did a "reply" on your email, it (tried to) sent it your personal email account rather than the list. -- Scott Bennett wrote: > > On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan > 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. (I happen to like, to the extent I understand it, GPLv3. But I don't see how it is relevant to this discussion and I don't know why it was injected into it.) > > >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. > Insecure clients installed > virally onto systems without notice to the users endanger those users. 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 people are not harming others reeks (IMO) of unsavory things like police states and nanny states. I am opposed. It is personal perspective, not 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. 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 discretion." As long as it could be disabled. But I really wonder why Tor developers would be interested in spending the time to implement such a thing. > > >with a friendly advisory as long is it wasn't incessant nagware that > >couldn't be disabled. But I don't understand the desire to dictate to > > I don't think the current log messages are so influential as all that. > Just take a look at the current consensus. :-( > > >people or some nanny viewpoint of trying to save people from > >themselves. (Before somebody makes an argument of keeping the Internet > >free of compromised machines, I rather imagine the number of machines > >compromised because of Tor software would be lost in the statistical > > Again, when the software is installed by stealth onto the machines > of unsuspecting users, then the probability on each user's machine becomes > 100%. In other words, the number of machines w.r.t. the user is 1 out of 1, > a ratio that cannot be considered "lost in the noise" for that user. By stealth??? If that is really so, I guess you could try to make the same argument about *any* free software that somebody decided to turn into malware. But I am still unconvinced the people who installed didn't know they were installing something. > >noise of all the other ways machines get compromised. And I don't think > >the unsavory purpose these "tbreg" instances are put to is a relevant > >factor.) > > > How so? I note that you deleted all the relevant context in your reply. I did not reproduce Pei Hanru's email in its entirety because I did not see it as necessary. Or particularly relevant for this discussion. As I stated, "I don't think the unsavory purpose these 'tbreg' instances are put to is a relevant factor." The unsavory purpose I referred to and perhaps what you call "relevant context" is the fact that Tor was part of software sold to (for the purpose of) (quoting Pei Hanru) "automatically register large number of TaoBao accounts." It is my opinion (yes, once again, *opinion*) that the fact that an unscrupulous person (or group of people) used the free software in question in a manner that *might* be analogous to certain freeware (*not* free software) actually being a trojan, i.e. malware that arguably was installed "by stealth," is not justification for taking a t
Re: 25 tbreg relays in directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Scott Bennett wrote: > On Sun, 28 Jun 2009 20:09:25 +0800 Pei Hanru > wrote: >> On 2009-04-27 18:27 CST, Scott Bennett wrote: >>> torstatus currently shows 25 different relays that are all named >>> "tbreq" >>> and appear to be in China. I wonder whether these are due to some benighted snip >> I've downloaded the software and tested, the version of Tor in it is >> indeed 0.2.1.2-alpha, torrc in it is > > Ouch. This provides another example in support of having a way for > the directory authorities to render insecure versions inoperable/unusable > as relays to the rest of the network and only usable as clients to connect > to the tor project's web site to download a current version of tor. How about simply take a page from Freenet? Each new build of Freenet comes with a "lastGoodVersion=" variable that contains the version number of the oldest build it's willing to talk to. Nodes older than that can't connect to the network for anything except updating the out of date node. - -- The best way to get past my spam filter is to sign or encrypt your email to me. My PGP KeyId: 0x84D46604 http://blogdoofus.com http://tinfoilchef.com http://www.domaincarryout.com Un-official Freenet 0.5 alternative download http://peculiarplace.com/freenet/ Mixminion Message Sender, Windows GUI Frontend for Mixminion http://peculiarplace.com/mixminion-message-sender/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBSki323V+YnyE1GYEAQgXmQf/VVTT7G8vMnOI222SVC7FKFZzH8ZHFvjn CuNHTqjkBRlN4L9zjv5Iya3UQtdSwQDTWCVpQM5UIP4wZFOVd3HcPjWD4KvSU2ST MLyH0v3Z14mHcFvMD6Z6F7fQYLwdOGdH22Zd95mtFbU3WtvtASOwjNcd0Al0+8ee NAERkThuVWzct+vfPDoxQgkWzlcJRK9BRSqrVgQPVsMqW/+n29WjuZL67r4N9Fza uF7g4jpLRptk9JaVcX1zDyPMoz/r5keX45ydaL4yluyg/6d3kQmoCRC6mBNN03HD bbJNge3BfGH3zTBOUp3uvai2x5u0PZnqfpdVblrOTlRNSXto4Xk/ag== =IQV6 -END PGP SIGNATURE-
Re: 25 tbreg relays in directory
On Mon, 29 Jun 2009 05:14:25 -0600 Jim McClanahan 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.) >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. Insecure clients installed virally onto systems without notice to the users endanger those users. >with a friendly advisory as long is it wasn't incessant nagware that >couldn't be disabled. But I don't understand the desire to dictate to I don't think the current log messages are so influential as all that. Just take a look at the current consensus. :-( >people or some nanny viewpoint of trying to save people from >themselves. (Before somebody makes an argument of keeping the Internet >free of compromised machines, I rather imagine the number of machines >compromised because of Tor software would be lost in the statistical Again, when the software is installed by stealth onto the machines of unsuspecting users, then the probability on each user's machine becomes 100%. In other words, the number of machines w.r.t. the user is 1 out of 1, a ratio that cannot be considered "lost in the noise" for that user. >noise of all the other ways machines get compromised. And I don't think >the unsavory purpose these "tbreg" instances are put to is a relevant >factor.) > How so? I note that you deleted all the relevant context in your reply. 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
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 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 with a friendly advisory as long is it wasn't incessant nagware that couldn't be disabled. But I don't understand the desire to dictate to people or some nanny viewpoint of trying to save people from themselves. (Before somebody makes an argument of keeping the Internet free of compromised machines, I rather imagine the number of machines compromised because of Tor software would be lost in the statistical noise of all the other ways machines get compromised. And I don't think the unsavory purpose these "tbreg" instances are put to is a relevant factor.)
Re: 25 tbreg relays in directory
On Mon, June 29, 2009 12:07, Pei Hanru wrote: > Someone hinted in a local forum that those "tbreg"s are related with > Taobao. So I googled and found out what I've described. That's it. like this: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.wintaobao.com%2Fhelp%2Ftbreg-auto%2F&sl=zh-CN&tl=en&history_state0= thanks again for the info :-) -- Marco Bonetti BT3 EeePC enhancing module: http://sid77.slackware.it/bt3/ Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My GnuPG key id: 0x86A91047
Re: 25 tbreg relays in directory
On 2009-06-29 13:24 CST, Curious Kid wrote: [...] >> I finally got a plausible answer a few days ago. >> > > Can you tell us how you came upon this information? I would be very > interested to know. Someone hinted in a local forum that those "tbreg"s are related with Taobao. So I googled and found out what I've described. That's it. Hanru
Re: 25 tbreg relays in directory
- Original Message > From: Pei Hanru > To: or-talk@freehaven.net > Sent: Sunday, June 28, 2009 2:09:25 PM > Subject: Re: 25 tbreg relays in directory > > On 2009-04-27 18:27 CST, Scott Bennett wrote: > > torstatus currently shows 25 different relays that are all named > > "tbreq" > > 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". > > I finally got a plausible answer a few days ago. > Can you tell us how you came upon this information? I would be very interested to know.
Re: 25 tbreg relays in directory
On Sun, 28 Jun 2009 20:09:25 +0800 Pei Hanru wrote: >On 2009-04-27 18:27 CST, Scott Bennett wrote: >> torstatus currently shows 25 different relays that are all named "tbreq" >> 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". > >I finally got a plausible answer a few days ago. > >The short answer is, someone are making use of Tor to do nasty things, >and all "tbreg"s aren't aware they are running Tor relays. > >The long answer. > >"tbreg" stands for "TaoBao REGistrar". TaoBao is an eBay-like website in >China. Some sellers want to quickly increase their reputations >(so-called refresh) in order to attract more buyers. The first thing for >them is to register multiple accounts. However, TaoBao is rigorous on >this, a single IP is only allowed to register one or two accounts. So, >someone realize this need and begin to sell softwares which >automatically register large number of TaoBao accounts. Tor, together >with Privoxy are used as a HTTP proxy to bypass the IP restriction. For Remarkable. >some reasons I don't understand, this software will run Tor as a relay. Perhaps the perverts misunderstood that they were configuring tor in their package to run as a relay when all they needed for their purpose was a client. > >I've downloaded the software and tested, the version of Tor in it is >indeed 0.2.1.2-alpha, torrc in it is Ouch. This provides another example in support of having a way for the directory authorities to render insecure versions inoperable/unusable as relays to the rest of the network and only usable as clients to connect to the tor project's web site to download a current version of tor. > > SocksPort 9050 # what port to open for local application connections > SocksListenAddress 127.0.0.1 # accept connections only from localhost > ControlPort 9051 > Nickname tbreg > ORPort 9001 > >You may test yourself, the download link is >http://www.wintaobao.com/download/tbreg_v1.3.8.msi (from >http://bbs.wintaobao.com/viewthread.php?tid=135). > >Finally some random thoughts. > >1. We shall be reassured for a moment, these relays won't do much harm >to the Tor network. I'm more concerned about the people running these >relays, their computers aren't protected at all. But considering the >things these guys are doing... well, let it go! Given the possible harms to which the victims may be subject, this is an argument in favor of having a way for the directory authorities to assign the Invalid flag to a group of nodes in an automated fashion based upon some easily recognizable characteristic they share, in this case, the Nickname. Because the node IDs (key fingerprints), IP addresses, etc. come and go, it needs to be an automated method, so that the directory authority operators can tell their nodes to invalidate all nodes with the common characteristic. > >2. Why Tor runs in a relay mode? > >3. Should these "tbreg"s be banned from the Tor network? If so, what's >the best way to do? > I've already weighed in on this, so I'll wait to see the (possibly updated) views of others before making further comments. Thank you *very* much for all your sleuthing in clearing up this mystery. 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
Nice work tracking that down.. Thanks for the info and time. I'm not a Tor dev but as a person working with/in IT, I can appreciate the time and legwork involved.. so thanks. -- free...@gmail.com free...@yahoo.ca This e-mail has been digitally signed with GnuPG - ( http://gnupg.org/ ) signature.asc Description: PGP signature
Re: 25 tbreg relays in directory
On 2009-04-27 18:27 CST, Scott Bennett wrote: > torstatus currently shows 25 different relays that are all named "tbreq" > 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". I finally got a plausible answer a few days ago. The short answer is, someone are making use of Tor to do nasty things, and all "tbreg"s aren't aware they are running Tor relays. The long answer. "tbreg" stands for "TaoBao REGistrar". TaoBao is an eBay-like website in China. Some sellers want to quickly increase their reputations (so-called refresh) in order to attract more buyers. The first thing for them is to register multiple accounts. However, TaoBao is rigorous on this, a single IP is only allowed to register one or two accounts. So, someone realize this need and begin to sell softwares which automatically register large number of TaoBao accounts. Tor, together with Privoxy are used as a HTTP proxy to bypass the IP restriction. For some reasons I don't understand, this software will run Tor as a relay. I've downloaded the software and tested, the version of Tor in it is indeed 0.2.1.2-alpha, torrc in it is SocksPort 9050 # what port to open for local application connections SocksListenAddress 127.0.0.1 # accept connections only from localhost ControlPort 9051 Nickname tbreg ORPort 9001 You may test yourself, the download link is http://www.wintaobao.com/download/tbreg_v1.3.8.msi (from http://bbs.wintaobao.com/viewthread.php?tid=135). Finally some random thoughts. 1. We shall be reassured for a moment, these relays won't do much harm to the Tor network. I'm more concerned about the people running these relays, their computers aren't protected at all. But considering the things these guys are doing... well, let it go! 2. Why Tor runs in a relay mode? 3. Should these "tbreg"s be banned from the Tor network? If so, what's the best way to do? Hanru
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
On Mon, May 25, 2009 at 08:04:13PM -0600, scr...@nonvocalscream.com wrote 0.6K bytes in 17 lines about: : Has this been discussed with the Ubuntu packagers? Is there a link to the : discussion I can read... I'm a user of Ubuntu and would be very interested : in being able to update via apt (repository). Yes, see this thread, http://archives.seul.org/or/talk/Apr-2009/msg00062.html Or just read this message from Roger, http://archives.seul.org/or/talk/Apr-2009/msg00065.html -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
Roger Dingledine wrote: [...] > 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. You should cut off all insecure relays, because some people might rely on Tor for providing strong anonymity. Security and anonymity should be more important than speed.
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
On Tue, May 26, 2009 at 1:24 PM, Sebastian Hahn wrote: > In short: Tor provides working Ubuntu packages in the noreply repositories, > so users can simply use those to get working, up-to-date, secure versions. > Because Tor is in Ubuntu Universe, no security updates are provided by > Ubuntu itself, meaning that Ubuntu used to ship remote-root vulnerable > versions of Tor for a long time, even though they were informed about the > problem and could simply have adopted the packages from noreply. As it > stands, I personally deem any package in Ubuntu universe as a great risk to > anyones computer security, since updates are not provided in a timely > manner. That being said, I'm very happy with the current situation (Tor > being removed from Ubuntu, while users can install packages from noreply > without any trouble to get the latest version of Tor). The packages were outdated simply because no one wanted to maintain the packages in ubuntu. You do not have to be an ubuntu developer to do this (you can have a developer sponsor the upload of your package), but you need to know how to package software for ubuntu. The problem seems to be that people are interested _now_. That isn't good enough if we tor in ubuntu to be maintained and well taken care of. If you start working on a project like this, you have to keep doing so. Or at least find someone else who can take over for you. I am going to look into the process of becoming an ubuntu developer (better than having all of my uploads sponsored) and then try to get tor back in ubuntu. When that time comes, I'll send an email to the list so that other people can help out too. -- Runa Sandvik
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 8:35 AM, Nils Vogels wrote: On Tue, May 26, 2009 at 4:04 AM, wrote: On Mon, 25 May 2009 16:59:33 -0400, Roger Dingledine wrote: 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. Has this been discussed with the Ubuntu packagers? Is there a link to the discussion I can read... I'm a user of Ubuntu and would be very interested in being able to update via apt (repository). Same here! I am using Ubuntu from apt (but only as a client), and if needed I could also provide updates. I used to be a package maintainer for FreeBSD, but have moved completely off to Linux these days. If the packagers need some help or are in time constraints, feel free to drop me a line. Grtz! The problem with Ubuntu can be followed by reading https://bugs.launchpad.net/ubuntu/intrepid/+source/tor/+bug/328442 In short: Tor provides working Ubuntu packages in the noreply repositories, so users can simply use those to get working, up-to- date, secure versions. Because Tor is in Ubuntu Universe, no security updates are provided by Ubuntu itself, meaning that Ubuntu used to ship remote-root vulnerable versions of Tor for a long time, even though they were informed about the problem and could simply have adopted the packages from noreply. As it stands, I personally deem any package in Ubuntu universe as a great risk to anyones computer security, since updates are not provided in a timely manner. That being said, I'm very happy with the current situation (Tor being removed from Ubuntu, while users can install packages from noreply without any trouble to get the latest version of Tor). Please see https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian if you want to learn more. Sebastian -BEGIN PGP SIGNATURE- iEYEARECAAYFAkob0YoACgkQCADWu989zuYTXgCgv81g1FMVpADa9CmHC7gDovLt A2gAoJFG16H3clai4PCs5QMruKZX6d/x =PjMT -END PGP SIGNATURE-
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
On Tue, May 26, 2009 at 4:04 AM, wrote: > > On Mon, 25 May 2009 16:59:33 -0400, Roger Dingledine wrote: > >> 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. > > > Has this been discussed with the Ubuntu packagers? Is there a link to the > discussion I can read... I'm a user of Ubuntu and would be very interested > in being able to update via apt (repository). Same here! I am using Ubuntu from apt (but only as a client), and if needed I could also provide updates. I used to be a package maintainer for FreeBSD, but have moved completely off to Linux these days. If the packagers need some help or are in time constraints, feel free to drop me a line. Grtz! -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
Re: Out-of-date Tors (was Re: 25 tbreg relays in directory)
On Mon, 25 May 2009 16:59:33 -0400, Roger Dingledine wrote: > 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. Has this been discussed with the Ubuntu packagers? Is there a link to the discussion I can read... I'm a user of Ubuntu and would be very interested in being able to update via apt (repository). Thanks, Jon (scream)
Out-of-date Tors (was Re: 25 tbreg relays in directory)
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
> v
Re: 25 tbreg relays in directory
On Thu, 30 Apr 2009 16:59:58 -0400 Andrew Lewman wrote: >On Mon, 27 Apr 2009 23:57:17 -0500 (CDT) >Scott Bennett wrote: > >In general, these options seem a fine way to partition the tor >network. Possibly more so for new releases and arbitraging the time >during which clients and relays upgrade. Tor clients already don't Well, the developers themselves did that a while back when they cut off the non-V2Dir-capable clients and servers, right? >trust the relays. The risk is possibly more to the relay operator than How so? Does a client refuse to use a relay whose version is not in the server-versions list distributed in the V3 consensus documents or the V2 status documents? >the tor clients using their relay. It's their OS in most cases that's >at risk, not so much the Tor network. > >> 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. > >An option to allow your client to only select from a list of relays >running a version as agreed by the DA's as recommended seems the better >of your a vs b. Well, yes, I thought quite a while before suggesting a), but also realized that there can be quite a long delay and upheaval involved in a change to the directory standard and protocol, so I suggested the use of b) in the interim. Suggestion a) is, in the long run, a better approach. > >We should stop talking about making the relay trust the client. I >don't think implementing a DRM scheme serves Tor in any way. If you That was not me, FWIW. However, I did suggest that a client not trust *itself* if its own version were not listed in client-versions in the V3 consensus or the V2 status. >think of Tor like TCP, then the whole discussion gets silly. Tor is an >anonymizing protocol on top of tcp/ip, for now. Hidden services and Right. It would be good to have an SCTP implementation of tor someday. >such are example applications that use Tor, the protocol. > >Roger and I have had conversations about this thread in taxis, train >stations, and the like as we've been traveling. I'm sure he'll comment My goodness! I had no idea that it would really generate much interest among developers. I only hoped so. >at some point. > I predict that will interesting. :-) 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 Mon, 27 Apr 2009 23:57:17 -0500 (CDT) Scott Bennett wrote: In general, these options seem a fine way to partition the tor network. Possibly more so for new releases and arbitraging the time during which clients and relays upgrade. Tor clients already don't trust the relays. The risk is possibly more to the relay operator than the tor clients using their relay. It's their OS in most cases that's at risk, not so much the Tor network. > 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. An option to allow your client to only select from a list of relays running a version as agreed by the DA's as recommended seems the better of your a vs b. We should stop talking about making the relay trust the client. I don't think implementing a DRM scheme serves Tor in any way. If you think of Tor like TCP, then the whole discussion gets silly. Tor is an anonymizing protocol on top of tcp/ip, for now. Hidden services and such are example applications that use Tor, the protocol. Roger and I have had conversations about this thread in taxis, train stations, and the like as we've been traveling. I'm sure he'll comment at some point. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
Re: 25 tbreg relays in directory
On Tue, 28 Apr 2009 23:14:35 -0500 (CDT) Scott Bennett wrote: > 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, Yes, these are warm, fuzzy, and nice methods. They are not software nor technical solutions to the problems you raise. They are merely a first step in awareness. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
Re: Version checking (was Re: 25 tbreg relays in directory)
On 30.04.09 00:24, Tripple Moon wrote: > Yes I agree that those other factors, which were not mentioned yet, are > ofcourse also elements to take into account for differences. And like i > previously already admitted this is a difficult topic to make foolproof. Actually you don't come with any concrete suggestions how you would like to do it. That is not surprising because what you want to do is impossible. > But...i disagree with your argument that my approach would contradict the > idea of Open-Source as that has noting todo with program's operational > logic but more with the public availability of the source codes. Ok. Lets examine: 1) You publish source code - ok. But that alone is not open source. 2) You want to prevent people from compiling the code themselves. 3) You want to prevent people from changing and using the code. 4) You want to prevent people from writing alternative implementations. I don't see how you can do this and still claim to support open source. (Maybe you should read some more at http://www.fsf.org/ and http://www.opensource.org/.) [I will skip the rest, it would be a repetition.] > I think we all agree that there is a growing need to "somehow" keep the tor > network operating at maximum compatibility and stability. If the tor > application wont get means to authenticate itself's internals, then im > afraid (IMHO) we will be looking at a future with *many* independent tor > networks who are not connected to each others cloud because of > differences... For the purpose of inter-operability of networks or parts of a network there exist design specifications which exactly describe how a client must behave. It is not important, which language is used for programming or which platform, compiler, libs, etc. as long as the software behaves according to that. (Would you require that all the systems connected to the internet are authenticated the way you desire? The result would be a mono-culture of systems which will all fail at the same time with the same problem.) The only thing you _might_ do: check for specific (mis-)behaviour of a given node. (But the internet would not exist in its current form if the systems are not at least partially accepting non-conforming behaviour.) And if someone writes a client not behaving? First the chance is high, that it will give a 'bad' user experience (performance, but most of all anonymity). There is then little chance that that client will gain enough distribution to be relevant. But if it does and it finally result in a split of networks? Ok, let the better one win. ;-) Regards, Dominik
Re: Version checking (was Re: 25 tbreg relays in directory)
Tripple Moon wrote: > IMHO, all and i mean *all* modifications of the original code and/or design > should be committed to the development-tree, that's how things get improved > and fixed etc by the community that maintains the development of the project. The problem with your logic (leaving aside the questions of whether it is desire or doable) is that it is *source* code that gets committed to the development tree, but you are wanting to authenticate against *object* code (at least that's what it used to be called), i.e., binaries. If there were a way to authenticate against *source* code (yeah, right) then your plan might be doable, even if not desirable. But when I compile my code (and I do), the resulting binary is dependent on the particulars of my system. I suspect if I compiled it on two different machines (and I have) I would get two different binaries even when I start with the same source. > If the tor application wont get means to authenticate itself's internals, then im afraid (IMHO) we will be looking at a future with *many* independent tor networks who are not connected to each others cloud because of differences... The need is for the code to be interoperable. Interoperability is a much lower threshold than authenticating binaries people run. Presumably your desire to authenticate stems from lack of trust -- i.e. fear of an attacker. But attackers are (or can be) clever and I don't think that even in *prinicple* you can reliably authenticate w/o requiring things that would destroy anonymity. That is, before you can trust me, you have to know who I am (with certainty) and what I am doing. If you don't know who I am I can tell you anything I want (such as what binary I'm running) and you won't know the difference.
Re: Version checking (was Re: 25 tbreg relays in directory)
--- On Wed, 4/29/09, Dominik Schaefer wrote: > From: Dominik Schaefer > Subject: Re: Version checking (was Re: 25 tbreg relays in directory) > To: or-talk@freehaven.net > Date: Wednesday, April 29, 2009, 7:18 AM > On 29.04.09 12:33, Tripple Moon wrote: > >> Also what would be gained from a CRC based on the > *binary*? > >> Wouldn't that change according to the system > that compiled it? > > Yes it *will* chance depending on the compiled > (source-)version and architecture and compiler used. > > But those variables are far less in quantity as the > possible individual modified versions > It will not only change with architecture, exact versions > of compiler and OS, > and source code revision (think of all the people using the > svn/git repo), but > also with compiler options controlling optimization/code > generation, ABI, > statically vs. dynamically linked libs and probably a bunch > of other. As you > combine all these you create a huge amount of possible > permutations. > But it is anyway useless, because any client can upload any > data it wants to > and claim it is its own binary. > BTW: Do you know, that there are independent > implementations of Tor based on > the official design documents? And that this is actually > encouraged by the > authors of Tor? > BTW2: Your approach of locking out other implementations > contradicts any idea > of open source and inter-operability. Yes I agree that those other factors, which were not mentioned yet, are ofcourse also elements to take into account for differences. And like i previously already admitted this is a difficult topic to make foolproof. (much like making any software foolproof infact) But...i disagree with your argument that my approach would contradict the idea of Open-Source as that has noting todo with program's operational logic but more with the public availability of the source codes. Same with interoperability which is also based on operational logic embedded in software... About those independent implementations: Ofcourse its a great way to improve any software that is Open-Source to allow independent modifications to the source code. But if those changes remain unknown to the development-team of the original software project, then *thats* where problems arise... Not only from a security P.O.V. but perhaps also concerning licensing violations... IMHO, all and i mean *all* modifications of the original code and/or design should be committed to the development-tree, that's how things get improved and fixed etc by the community that maintains the development of the project. We all know how M$ started, right old-guys around? ^^ (Yes billy G. there are still ppl walking around the planet who wont forget how you started that buggy OS) A---NNN---YYY--wayyy I think we all agree that there is a growing need to "somehow" keep the tor network operating at maximum compatibility and stability. If the tor application wont get means to authenticate itself's internals, then im afraid (IMHO) we will be looking at a future with *many* independent tor networks who are not connected to each others cloud because of differences...
Re: Version checking (was Re: 25 tbreg relays in directory)
Nils Vogels wrote: > IMHO, just adding a list of allowed versions in the consensus will > accomplish just that, without the need of all that extra traffic and > CRC complexity. Use as much donated network capacity as possible without reducing anonymity by treating exit nodes and other nodes differently: - Old exit nodes: Use them, but increase the circuit length by 1 - Other old nodes: Don't use them at all Old versions that are remotely exploitable should be automatically shutdown. Maybe the directory authorities could instruct them to do that?. If that's not possible, they should not be listed in the directory to reduce the risk of them getting compromised. That won't help for existing nodes with static IP, but it will help in other cases.
Re: Version checking (was Re: 25 tbreg relays in directory)
On Wed, 29 Apr 2009 04:04:42 -0700 (PDT) Tripple Moon wrote: >--- On Wed, 4/29/09, Scott Bennett wrote: >[cut] >> >All of the above can be waifed void, when those >> versions are announced on the mailing list. >> >> "Waifed"? What language are you borrowing >> that from? And what does >> it mean? "Waif" in English is a noun having a >> meaning that bears no >> obvious connection to this discussion. >> Hmm...on the off-chance that you intended to type >> "waived", I think I >> can see an intended meaning, although the use of the word >> is still incorrect in this context. >Yes apologies for my non-perfect English, im not a native English speaking >person :) >What i mean was those arguments can be eliminated. >(better now? :D) > Thank you for the clarification. I hope that the rest of what I wrote in response to your previous message, as well as what a few others have written, has made it clear to you why those arguments *cannot* be eliminated. 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 29.04.09 12:33, Tripple Moon wrote: >> Also what would be gained from a CRC based on the *binary*? >> Wouldn't that change according to the system that compiled it? > Yes it *will* chance depending on the compiled (source-)version and > architecture and compiler used. > But those variables are far less in quantity as the possible individual > modified versions It will not only change with architecture, exact versions of compiler and OS, and source code revision (think of all the people using the svn/git repo), but also with compiler options controlling optimization/code generation, ABI, statically vs. dynamically linked libs and probably a bunch of other. As you combine all these you create a huge amount of possible permutations. But it is anyway useless, because any client can upload any data it wants to and claim it is its own binary. BTW: Do you know, that there are independent implementations of Tor based on the official design documents? And that this is actually encouraged by the authors of Tor? BTW2: Your approach of locking out other implementations contradicts any idea of open source and inter-operability. Regards, Dominik
Re: Version checking (was Re: 25 tbreg relays in directory)
Tripple Moon (29.04.2009 17:33): >> 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? > Well yea thats upto the implementation of this behavior, and i wholeheartedly > would suggest to _not_ allow any uploads of external files. > By external files i mean using file-open routines, it should only upload the > current running instance of the tor-application. > And ofcourse like you already mentioned they could create a modified version > which indeed does what you say. > So this is a hard-egg to crack for me personally atm :) There is no way in the Universe to accomplish this. Do you see much (if any) unbreakable DRM systems around? Think about this for awhile. -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com
Re: Version checking (was Re: 25 tbreg relays in directory)
--- On Wed, 4/29/09, Scott Bennett wrote: [cut] > >All of the above can be waifed void, when those > versions are announced on the mailing list. > > "Waifed"? What language are you borrowing > that from? And what does > it mean? "Waif" in English is a noun having a > meaning that bears no > obvious connection to this discussion. > Hmm...on the off-chance that you intended to type > "waived", I think I > can see an intended meaning, although the use of the word > is still incorrect in this context. Yes apologies for my non-perfect English, im not a native English speaking person :) What i mean was those arguments can be eliminated. (better now? :D)
Re: Version checking (was Re: 25 tbreg relays in directory)
On Wed, 29 Apr 2009 03:13:52 -0700 (PDT) Tripple Moon wrote: >first off, please only reply to the mailing-list address otherwise ppl like me >are getting your messages double, just like you will get now... > My apologies. You did request that before, and I simply forgot. It is accepted courtesy on most mailing lists to address a followup both to the list and to the author of the article(s) being followed up. When someone asks me to deviate from that standard, I am happy to oblige, but just made a mistake in this case. I will try to remember better in the future. > >--- On Tue, 4/28/09, Scott Bennett wrote: >[cut for clarity] >> 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? >All of the above can be waifed void, when those versions are announced on the >mailing list. "Waifed"? What language are you borrowing that from? And what does it mean? "Waif" in English is a noun having a meaning that bears no obvious connection to this discussion. Hmm...on the off-chance that you intended to type "waived", I think I can see an intended meaning, although the use of the word is still incorrect in this context. Please keep in mind that tor is distributed in a number of forms, one of which is source code that can be compiled on any version of any system with a compatible C compiler and required libraries. I frankly doubt that anyone on this list or on the development team could come up with the definitive, comprehensive list of such systems. An item I missed when writing the list above is that the required libraries, which are independent of the tor project, of course, also come in a wide variety of versions, architectures, and operating system implementations and may have been compiled under a variety of different C compilers and versions. If my speculation about your intended meaning is correct, then on the face of it, your suggestion is outlandish. >> >> >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. >Ofcourse not silly >- More secure for the "anonymous tor user" because he will be forced to >upgrade its client to stay connected to the tor-network, if (s)he doesn't >upgrade his/her insecure client (s)he will be denied by other tor's to the >network. While simultaneously adding to his/her risk of breached anonymity? While offering him/her no anonymity at all in obtaining an up-to-date version? While still allowing, as another writer has pointed out (sorry, I've deleted the message and have forgotten who wrote it) already, a tampered client to send an unaltered copy for checking? >- More manageable for the tor development team, because they will know exactly >which versions are being used by current users of the tor program. The tor development team probably doesn't need to know that. They already make tor available in forms compatible with the most common systems, while providing source code for those who need/want to make it work on their own systems. For example, tor is available in precompiled bundles for Micro$lop Windows systems and Mac OS X systems. It is also available in forms for easy installation onto several kinds of LINUX systems. For UNIX systems other than Mac OS X, it is necessary to download the source and compile it. That includes *BSD systems, Solaris systems, and so on. I think you really need to spend more time thinking about the ramifications of what you suggest before posting them. >> >> >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. In case it is unclear to the casual reader, my statement above was in reference to any sort of verification of clients any other part of the tor network. Scott Bennett, Comm. ASMELG, CFIAG *
Re: Version checking (was Re: 25 tbreg relays in directory)
--- On Tue, 4/28/09, Ted Smith wrote: > From: Ted Smith > Subject: Re: Version checking (was Re: 25 tbreg relays in directory) > To: or-talk@freehaven.net > Date: Tuesday, April 28, 2009, 10:51 PM > 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. Well yes kind-of... But instead of the binary on file, the binary in memory... And the check could just as well be done by another already accepted node. Just like the trust rings work for SSL certificates, when a trusted certifacate issues a trust for another
Re: Version checking (was Re: 25 tbreg relays in directory)
--- On Tue, 4/28/09, Jim McClanahan wrote: > From: Jim McClanahan > Subject: Re: Version checking (was Re: 25 tbreg relays in directory) > To: or-talk@freehaven.net > Date: Tuesday, April 28, 2009, 12:01 PM > > 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! yes thats true, i admit thats a valid con argument. > > I am also wondering what kind of danger you think a > *client* can have > for the Tor network. Well AFAIK (from reading the global discourse), there seem to be some nodes primarily setup to monitor and/or (try-to) disrupt the data flow of the tor network by using altered clients with "enhanced/added" routines... Don't ask me to provide links, because i don't keep bookmarks of random info i read while searching for other info... (It could also be my personal distrustful mind playing tricks on me) > > 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? Well yea thats upto the implementation of this behavior, and i wholeheartedly would suggest to _not_ allow any uploads of external files. By external files i mean using file-open routines, it should only upload the current running instance of the tor-application. And ofcourse like you already mentioned they could create a modified version which indeed does what you say. So this is a hard-egg to crack for me personally atm :) > > Also what would be gained from a CRC based on the *binary*? > Wouldn't > that change according to the system that compiled it? Yes it *will* chance depending on the compiled (source-)version and architecture and compiler used. But those variables are far less in quantity as the possible individual modified versions
Re: Version checking (was Re: 25 tbreg relays in directory)
On 4/29/09, Tripple Moon wrote: > > > >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. > > Ofcourse not silly > - More secure for the "anonymous tor user" because he will be forced to > upgrade > its client to stay connected to the tor-network, if (s)he doesn't upgrade > his/her > insecure client (s)he will be denied by other tor's to the network. > - More manageable for the tor development team, because they will know > exactly which versions are being used by current users of the tor program. IMHO, just adding a list of allowed versions in the consensus will accomplish just that, without the need of all that extra traffic and CRC complexity. Greets, Nils -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
Re: Version checking (was Re: 25 tbreg relays in directory)
first off, please only reply to the mailing-list address otherwise ppl like me are getting your messages double, just like you will get now... --- On Tue, 4/28/09, Scott Bennett wrote: [cut for clarity] > 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? All of the above can be waifed void, when those versions are announced on the mailing list. > > >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. Ofcourse not silly - More secure for the "anonymous tor user" because he will be forced to upgrade its client to stay connected to the tor-network, if (s)he doesn't upgrade his/her insecure client (s)he will be denied by other tor's to the network. - More manageable for the tor development team, because they will know exactly which versions are being used by current users of the tor program. > > >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.
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: 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
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
Re: 25 tbreg relays in directory
On Mon, 27 Apr 2009 17:32:16 -0400 Roger Dingledine
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.
Re: 25 tbreg relays in directory
On Mon, Apr 27, 2009 at 05:27:38AM -0500, Scott Bennett wrote:
> torstatus currently shows 25 different relays that are all named "tbreq"
> 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.
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.
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. :)
--Roger
Re: 25 tbreg relays in directory
Scott Bennett wrote: torstatus currently shows 25 different relays that are all named "tbreq" 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". 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 * ** <> Hi Scott, Call me pramoid but for one user restarting tor the location are lying quite far from each other. anymway, just my 2 cts... Matthieu Dalissier
25 tbreg relays in directory
torstatus currently shows 25 different relays that are all named "tbreq" 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". 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 * **
