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)
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 benn...@cs.niu.edu 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: Version checking (was Re: 25 tbreg relays in directory)
On 4/29/09, Tripple Moon tripple.m...@yahoo.com 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)
--- On Tue, 4/28/09, Ted Smith ted...@gmail.com wrote: From: Ted Smith ted...@gmail.com 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 benn...@cs.niu.edu wrote: From: Scott Bennett benn...@cs.niu.edu 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 Wed, 29 Apr 2009 03:13:52 -0700 (PDT) Tripple Moon tripple.m...@yahoo.com 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 benn...@cs.niu.edu 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 ** * Internet: bennett
Re: Version checking (was Re: 25 tbreg relays in directory)
--- On Wed, 4/29/09, Scott Bennett benn...@cs.niu.edu 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)
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 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)
On Wed, 29 Apr 2009 04:04:42 -0700 (PDT) Tripple Moon tripple.m...@yahoo.com wrote: --- On Wed, 4/29/09, Scott Bennett benn...@cs.niu.edu 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)
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, 4/29/09, Dominik Schaefer schaed...@gmx.de wrote: From: Dominik Schaefer schaed...@gmx.de 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)
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.
Version checking (was Re: 25 tbreg relays in directory)
--- On Tue, 4/28/09, Scott Bennett benn...@cs.niu.edu wrote: From: Scott Bennett benn...@cs.niu.edu 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: Version checking (was Re: 25 tbreg relays in directory)
On Tue, 28 Apr 2009 03:01:30 -0700 (PDT) Tripple Moon tripple.m...@yahoo.com wrote: --- On Tue, 4/28/09, Scott Bennett benn...@cs.niu.edu wrote: From: Scott Bennett benn...@cs.niu.edu 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 * **
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: 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 benn...@cs.niu.edu wrote: From: Scott Bennett benn...@cs.niu.edu 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
